All,
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?
What requirements do we have to help us close on a solution?
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 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.
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 schema from the device itself. The
"instance" schema is aligned with the PWG schema.
Peter Zehler
XEROX
Xerox Architecture Center
Email: PZehler at 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