Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] WSDL soap:binding enhancement for SOAP version?

Expand Messages
  • noah_mendelsohn@us.ibm.com
    ... Amazingly, my reading of the spec is that you are both right. As best I can tell, Jacek is correctly citing [1], and then at [2] there is the statement:
    Message 1 of 13 , Jan 4, 2002
    • 0 Attachment
      Andrew Layman writes:

      > Unless this has been corrected recently, the
      > default "value" supplied by a schema is not
      > actually the value-space value but rather
      > the literal lexical representation
      > appearing in the schema

      and Jacek Kopecky writes:

      > from my reading of XML Schema, especially
      > section 3.2.1 [1], and in particular the
      > sentence "Note that it is values that are
      > supplied and/or checked, not strings," I
      > understand that the default value is from
      > value space, not from lexical space.

      Amazingly, my reading of the spec is that you are both right. As best I
      can tell, Jacek is correctly citing [1], and then at [2] there is the
      statement:

      "Validation Rule: Attribute Locally Valid

      For an attribute information item to be locally ·valid· with respect to an
      attribute declaration all of the following must be true:
      1 The declaration must not be ·absent· (see Missing Sub-components (§5.3)
      for how this can fail to be the case).
      2 Its {type definition} must not be absent.
      3 The item's ·normalized value· must be locally ·valid· with respect to
      that {type definition} as per String Valid (§3.14.4).
      4 The item's ·actual value· must match the value of the {value
      constraint}, if it is present and fixed."

      See particularly clause 4, which refers to "actual value". The definition
      of "actual value" is [3]: "[Definition:] The phrase actual value is used
      to refer to the member of the value space of the simple type definition
      associated with an attribute information item which corresponds to its
      ·normalized value·. This will often be a string, but may also be an
      integer, a boolean, a URI reference, etc. This term is also occasionally
      used with respect to element or attribute information items in a document
      being ·validated·."

      So, surely Jacek is right. But no! At [4] we find the information set
      contribution, which is:

      "Schema Information Set Contribution: Attribute Validated by Type

      If clause 3 of Attribute Locally Valid (§3.2.4) applies with respect to an
      attribute information item, in the post-schema-validation infoset the
      attribute information item has a property:

      [schema normalized value] -- The ·normalized value· of the item as
      ·validated·."

      ...and at [5] we find the definition of normalized value:

      "[Definition:] The normalized value of an element or attribute information
      item is an ·initial value· whose white space, if any, has been normalized
      according to the value of the whiteSpace facet of the simple type
      definition used in its ·validation·:"

      So Andrew is right too!

      If I have understood this correctly, comparison of "fixed" specifications
      is based on the value space, but the standard information set contribution
      is the input string (lexical form) after whitespace handling has been
      done.

      Henry: Do I have this right? If so, is this all intentional? In any
      case, I think there is a case to be made for a terminology erratum...using
      words like "normalized value" and "actual value" where one is lexical and
      the other is value space seems confusing at best. I suggest we provide
      some useful input to soapbuilders, then move the schema issues over to
      schema-comments or the schema IG list. Thanks.


      [1] http://www.w3.org/TR/xmlschema-1/#Attribute_Declaration_details
      [2] http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Validation-Rules
      [3] http://www.w3.org/TR/xmlschema-1/#key-vv
      [4] http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Information-Set-Contributions
      [5] http://www.w3.org/TR/xmlschema-1/#key-nv


      ------------------------------------------------------------------------
      Noah Mendelsohn Voice: 1-617-693-4036
      Lotus Development Corp. Fax: 1-617-693-8676
      One Rogers Street
      Cambridge, MA 02142
      ------------------------------------------------------------------------
    • Andrew Layman
      Thanks. It is probably also worth mentioning that the default lexical string of a qname is nearly useless, while the default value space value would be quite
      Message 2 of 13 , Jan 4, 2002
      • 0 Attachment
        Thanks.

        It is probably also worth mentioning that the default lexical string of a
        qname is nearly useless, while the default value space value would be quite
        useful. I would greatly prefer to become wrong on this and have Jacek
        definitely right. Note, however, that the value-space value of a qname is
        not a string, but the pair {ns-uri,localname} and that ns-uri may not
        actually have any in-scope prefix in the instance.

        Andrew Layman
        http://strongbrains.com -- Resources for Self-Education
        ----- Original Message -----
        From: <noah_mendelsohn@...>
        To: <soapbuilders@yahoogroups.com>; <ht@...>
        Cc: <andrewl@...>
        Sent: Friday, January 04, 2002 8:11 AM
        Subject: Re: [soapbuilders] WSDL soap:binding enhancement for SOAP version?


        Andrew Layman writes:

        > Unless this has been corrected recently, the
        > default "value" supplied by a schema is not
        > actually the value-space value but rather
        > the literal lexical representation
        > appearing in the schema

        and Jacek Kopecky writes:

        > from my reading of XML Schema, especially
        > section 3.2.1 [1], and in particular the
        > sentence "Note that it is values that are
        > supplied and/or checked, not strings," I
        > understand that the default value is from
        > value space, not from lexical space.

        Amazingly, my reading of the spec is that you are both right. As best I
        can tell, Jacek is correctly citing [1], and then at [2] there is the
        statement:

        "Validation Rule: Attribute Locally Valid

        For an attribute information item to be locally ·valid· with respect to an
        attribute declaration all of the following must be true:
        1 The declaration must not be ·absent· (see Missing Sub-components (§5.3)
        for how this can fail to be the case).
        2 Its {type definition} must not be absent.
        3 The item's ·normalized value· must be locally ·valid· with respect to
        that {type definition} as per String Valid (§3.14.4).
        4 The item's ·actual value· must match the value of the {value
        constraint}, if it is present and fixed."

        See particularly clause 4, which refers to "actual value". The definition
        of "actual value" is [3]: "[Definition:] The phrase actual value is used
        to refer to the member of the value space of the simple type definition
        associated with an attribute information item which corresponds to its
        ·normalized value·. This will often be a string, but may also be an
        integer, a boolean, a URI reference, etc. This term is also occasionally
        used with respect to element or attribute information items in a document
        being ·validated·."

        So, surely Jacek is right. But no! At [4] we find the information set
        contribution, which is:

        "Schema Information Set Contribution: Attribute Validated by Type

        If clause 3 of Attribute Locally Valid (§3.2.4) applies with respect to an
        attribute information item, in the post-schema-validation infoset the
        attribute information item has a property:

        [schema normalized value] -- The ·normalized value· of the item as
        ·validated·."

        ...and at [5] we find the definition of normalized value:

        "[Definition:] The normalized value of an element or attribute information
        item is an ·initial value· whose white space, if any, has been normalized
        according to the value of the whiteSpace facet of the simple type
        definition used in its ·validation·:"

        So Andrew is right too!

        If I have understood this correctly, comparison of "fixed" specifications
        is based on the value space, but the standard information set contribution
        is the input string (lexical form) after whitespace handling has been
        done.

        Henry: Do I have this right? If so, is this all intentional? In any
        case, I think there is a case to be made for a terminology erratum...using
        words like "normalized value" and "actual value" where one is lexical and
        the other is value space seems confusing at best. I suggest we provide
        some useful input to soapbuilders, then move the schema issues over to
        schema-comments or the schema IG list. Thanks.


        [1] http://www.w3.org/TR/xmlschema-1/#Attribute_Declaration_details
        [2]
        http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Validation-R
        ules
        [3] http://www.w3.org/TR/xmlschema-1/#key-vv
        [4]
        http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Information-
        Set-Contributions
        [5] http://www.w3.org/TR/xmlschema-1/#key-nv


        ------------------------------------------------------------------------
        Noah Mendelsohn Voice: 1-617-693-4036
        Lotus Development Corp. Fax: 1-617-693-8676
        One Rogers Street
        Cambridge, MA 02142
        ------------------------------------------------------------------------





        -----------------------------------------------------------------
        This group is a forum for builders of SOAP implementations to discuss
        implementation and interoperability issues. Please stay on-topic.

        To unsubscribe from this group, send an email to:
        soapbuilders-unsubscribe@yahoogroups.com



        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • noah_mendelsohn@us.ibm.com
        Henry is not on soapbuilders, so I am forwarding this note for him (with his permission). For those who don t know, Henry is an editor of the schema
        Message 3 of 13 , Jan 7, 2002
        • 0 Attachment
          Henry is not on soapbuilders, so I am forwarding this note for him (with
          his permission). For those who don't know, Henry is an editor of the
          schema structures spec, and is expert in the sort of details we're
          discussing.

          ------------------------------------------------------------------------
          Noah Mendelsohn Voice: 1-617-693-4036
          Lotus Development Corp. Fax: 1-617-693-8676
          One Rogers Street
          Cambridge, MA 02142
          ------------------------------------------------------------------------



          ----- Forwarded by Noah Mendelsohn/CAM/Lotus on 01/07/2002 02:28 PM -----


          ht@... (Henry S. Thompson)
          01/07/2002 08:28 AM


          To: Noah Mendelsohn/CAM/Lotus@Lotus
          cc: soapbuilders@yahoogroups.com, andrewl@...
          Subject: Re: [soapbuilders] WSDL soap:binding enhancement for SOAP version?


          noah_mendelsohn@... writes:

          > Andrew Layman writes:
          >
          > > Unless this has been corrected recently, the
          > > default "value" supplied by a schema is not
          > > actually the value-space value but rather
          > > the literal lexical representation
          > > appearing in the schema
          >
          > and Jacek Kopecky writes:
          >
          > > from my reading of XML Schema, especially
          > > section 3.2.1 [1], and in particular the
          > > sentence "Note that it is values that are
          > > supplied and/or checked, not strings," I
          > > understand that the default value is from
          > > value space, not from lexical space.
          >
          > Amazingly, my reading of the spec is that you are both right. As best I
          > can tell, Jacek is correctly citing [1], and then at [2] there is the
          > statement:
          >
          > "Validation Rule: Attribute Locally Valid
          >
          > For an attribute information item to be locally ·valid· with respect to
          an
          > attribute declaration all of the following must be true:
          > 1 The declaration must not be ·absent· (see Missing Sub-components
          (§5.3)
          > for how this can fail to be the case).
          > 2 Its {type definition} must not be absent.
          > 3 The item's ·normalized value· must be locally ·valid· with respect to
          > that {type definition} as per String Valid (§3.14.4).
          > 4 The item's ·actual value· must match the value of the {value
          > constraint}, if it is present and fixed."
          >
          > See particularly clause 4, which refers to "actual value". The
          definition
          > of "actual value" is [3]: "[Definition:] The phrase actual value is
          used
          > to refer to the member of the value space of the simple type definition
          > associated with an attribute information item which corresponds to its
          > ·normalized value·. This will often be a string, but may also be an
          > integer, a boolean, a URI reference, etc. This term is also occasionally
          > used with respect to element or attribute information items in a
          document
          > being ·validated·."
          >
          > So, surely Jacek is right. But no! At [4] we find the information set
          > contribution, which is:
          >
          > "Schema Information Set Contribution: Attribute Validated by Type
          >
          > If clause 3 of Attribute Locally Valid (§3.2.4) applies with respect to
          an
          > attribute information item, in the post-schema-validation infoset the
          > attribute information item has a property:
          >
          > [schema normalized value] -- The ·normalized value· of the item as
          > ·validated·."
          >
          > ...and at [5] we find the definition of normalized value:
          >
          > "[Definition:] The normalized value of an element or attribute
          information
          > item is an ·initial value· whose white space, if any, has been
          normalized
          > according to the value of the whiteSpace facet of the simple type
          > definition used in its ·validation·:"
          >
          > So Andrew is right too!
          >
          > If I have understood this correctly, comparison of "fixed"
          specifications
          > is based on the value space, but the standard information set
          contribution
          > is the input string (lexical form) after whitespace handling has been
          > done.
          >
          > Henry: Do I have this right?

          Yes.

          > If so, is this all intentional?

          Yes. Without getting in to implementation details, how could we have
          gone further wrt the PSVI [schema normalized value] property?

          > [1] http://www.w3.org/TR/xmlschema-1/#Attribute_Declaration_details
          > [2] http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Validation-Rules
          > [3] http://www.w3.org/TR/xmlschema-1/#key-vv
          > [4] http://www.w3.org/TR/xmlschema-1/#section-Attribute-Declaration-Information-Set-Contributions
          > [5] http://www.w3.org/TR/xmlschema-1/#key-nv

          ht
          --
          Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
          2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
          Fax: (44) 131 650-4587, e-mail: ht@...
          URL: http://www.ltg.ed.ac.uk/~ht/
        Your message has been successfully submitted and would be delivered to recipients shortly.