All,
Here is the corrected background on the keyword extension issue. Sorry for
the mistake but I am working off a couple of systems right now and I sent
out the incomplete version the first time. I will send out shorter mail
notes to start off conversations on the 2 issues below.
Pete
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler@crt.xerox.com
Voice: (585) 265-8755
FAX: (585) 265-8871
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-30E
Webster NY, 14580-9701
_____________________________________________________________
The current issue at hand is the mechanism to allow the extension of the
semantic model schema. Extension of the defined objects with new elements
is accomplished via the xsd:any element and not at issue. There are four
different ways under consideration for the ability to accommodate the
extension of VALUES for an element. The four methods are listed below with a
brief description. (Let me know if there are other possibilities)
I am curious about the objectives that drive the resolution of this issue.
It seems to me that the primary objectives are to
A) Insure that the schema for the print model is easily
extended. For both vendors and sites. The extensions should be allowed at
both the object and semantic element value levels.
B) Enable print client developers to ascertain the capabilities
of a print device at runtime.
I think I heard a requirement that a client be able to determine that a
request is well formed, in the PWG schema sense, using XML tools and the PWG
schema. Am I hearing that requirement correctly?
ISSUE 1:
What requirements do we have to help us close on a solution?
ISSUE 2:
What are your opinions on the 4 solutions below?
The last teleconference left off with us leaning towards #3 below. I have
some doubts about this after thinking it over. I was not sure how a client
after issuing a GetPrinterAttributes would know how to properly encode an
extended finishing option.
Comments?
Pete
______________________________________________________________________
1)appinfo: The method used in the existing schema.
("<ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Schema/PwgAttr.xsd>") There are
no restrictions places on the values for our PWG Keywords elements. The
semantic elements are defines by an unrestricted base type. The well-known
values are held in appinfo elements that decorate the semantic element. XML
parsers do not use appinfo from the schema when validating the xml instance
document. The values are passed from the client to the server allowing the
application to validate the values. Xml tools do not use appinfo when
providing list of values that an element can take on. However print clients
are not built just using xml tools. An xml aware application (i.e. Print
Client) can use the application information (i.e. well-known values)
provided in appinfo to populate pull down lists or dialogues in any manner
the application developer see fit. One issue is that it is not known if all
xml tools will make the appinfo information available to the application.
2)union: This method is shown in "
<ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Schema/union.xsd> (xml, doc)".
This method places partial restrictions on the values for our PWG keyword
elements. The semantic element definition uses the union data type to
provide value space from a union of two or more data types. One data type is
defined using the enumeration facet to restrict the values allowed to the
well-known values. A second data type uses the pattern facet to establish
the rules for the added values. The semantic element is defined using a
union of these two (or more) data types. XML parsers use the enumerations
from the schema when validating the xml instance document. Since the union
uses a combination of an enumeration and a pattern the allowed values are
not restricted to the well-known values defined in the schema. The values
adhering to the established rules are passed from the client to the server
allowing the application to validate the values. Xml tools do use the
enumerations when providing list of values that an element can take on.
Note that these values are non-localized keywords. However print clients
are not built just using xml tools. An xml aware application (i.e. Print
Client) can use the application information (i.e. well-known values)
provided in enumerations to populate pull down lists or dialogues in any
manner the application developer see fit. This solution is slightly more
complicated in that the base types and the unions must be defined. The
pattern type will only need to be defined once and reused throughout. One
issue is how existing WSDL tools will handle this complication.
3)link This method is shown in "
<ftp://ftp.pwg.org/pub/pwg/Semantic-Model/Schema/link.xsd> (xml, doc)".
This method places complete restrictions on the values for our PWG keyword
elements. The semantic element definition uses the NMTOKEN data type and
the enumeration facet to restrict the values allowed to the well-known
values. A container, such as a job or document, allows new elements to be
added. In this model for extensibility, no new values may be added to the
semantic element itself. To extend the semantic element a new element is
added to the container. The semantic element has an optional attribute to
"point" to the new element that contains the extended value. XML parsers
use the enumerations from the schema when validating the xml instance
document. Only well-known values are allowed for the semantic element. The
extended element would probably also restrict the allowed extended values.
Xml tools do use the enumerations when providing list of values that a
semantic element or extended element can take on. Note that these values
are non-localized keywords. Standard XML tools would not understand the
linking of the elements. An xml aware application (i.e. Print Client) can
use the linkage information to provide a combined list of allowed values to
populate pull down lists or dialogues in any manner the application
developer see fit. This solution is more complicated in that the Print
Client is responsible for encoding the selected values into the appropriate
element and establishing the link. One issue is how clients would be made
aware of the "instance schema" that indicates this extension.
4) Derived schemas This method uses local schemas that are aligned with
the PWG semantics. Transforms can be written that will take the appinfo in
method 1 above and generate a series of enumerations from them that apply to
the associated semantic element. The modified schema can be used locally to
validate the element values against the PWG schema. Note that this does not
determine if the target instance supports the semantic element value. Other
similar solutions involve retrieving the "instance schema" from the device
itself. The "instance schema" is aligned with the PWG schema.
This archive was generated by hypermail 2b29 : Thu Sep 26 2002 - 08:44:20 EDT