Semantic Model Mail Archive: SM> CORRECTED Keyword Extension

Semantic Model Mail Archive: SM> CORRECTED Keyword Extension

SM> CORRECTED Keyword Extension Mechanism for schema

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Thu Sep 26 2002 - 08:43:42 EDT

  • Next message: Zehler, Peter: "SM> Keyword Extension ISSUE 1"

    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