I think we also briefly talked about a fifth option last week, and
we have some internal HP folks that prefer this approach:
5)derived schemas:
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 schema is
created that inherits the base pwg schema. In this schema, any new values
are declared and the semantic element is redefined with the union of the
original values and the newly declared values. XML parsers use the
enumerations from the schema referred to in the instance document when
validating the xml instance document. If the original pwg schema is
referenced,
only well-known values are allowed for the semantic element. If the
"superset"
schema is referenced, the well-known value plus the newly defined values
are used as enumerations. 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. One issue is how clients
would
be made aware of the "superset schema" that indicates this extension.
bt
> -----Original Message-----
> From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
> Sent: Thursday, September 26, 2002 5:44 AM
> To: PWG Semantic Model WG (E-mail)
> Subject: SM> CORRECTED Keyword Extension Mechanism for schema
>>> 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 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
>> _____________________________________________________________
> 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.
>