Semantic Model Mail Archive: SM> Keyword Extension Mechanism

SM> Keyword Extension Mechanism for schema

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Tue Sep 24 2002 - 15:03:02 EDT

  • Next message: Zehler, Peter: "SM> No Semantic Model Telecon 9/26, Next Semantic Model Telecon 10/3 <eom>"

    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@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



    This archive was generated by hypermail 2b29 : Tue Sep 24 2002 - 15:04:17 EDT