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

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

Expand Messages
  • Jacek Kopecky
    Andrew, 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,
    Message 1 of 13 , Jan 4, 2002
    • 0 Attachment
      Andrew,
      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.
      If this is the case, before the split we could not use the
      XML Schema defaulting mechanism because the sizes had to be
      filled in in the actual array instance. After the split, we can
      default the type and the sizes can still be filled in
      independently.
      On the other hand if the default value was from lexical space,
      it would be useless for qnames (as you correctly point out) and
      therefore this should be a bug of XML Schema and an errata entry
      ASAP. 8-)
      Do you agree that if the XML Schema default are values, not
      lexical forms, the split makes sense and we don't need any more
      wsdl:... extensions to XML Schema?
      Best regards,

      Jacek Kopecky

      Senior Architect, Systinet (formerly Idoox)
      http://www.systinet.com/

      [1] http://www.w3.org/TR/xmlschema-1/#Attribute_Declaration_details



      On Thu, 27 Dec 2001, Andrew Layman wrote:

      > There is a problem with namespace prefixes and default values in XML Schemas
      > that is addressed by the WSDL ArrayType attribute. 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 -- which might bind to a different value or no value
      > at all in an XML instance such as a SOAP message..
      >
      > The proposed split of the SOAP Encoding arrayType attribute into two
      > attributes does not reduce the problem. I actually do not see that the
      > proposed split solves any problem.
      >
      > Specifically, if a default value is supplied for a qname-typed attribute in
      > a schema, the default value will, of course, contain a namespace prefix.
      > However, there is no guarantee that that same prefix will bind to the same
      > namespace URI in a SOAP message as it did in the schema.
      >
      > The purpose of the WSDL ArrayType attribute is to solve this by stating that
      > the array type of the controlled instance element is determined by the
      > namespace URI associated with the namespace prefix in the schema.
      >
      > Andrew Layman
      > http://strongbrains.com -- Resources for Self-Education
      > ----- Original Message -----
      > From: "Jacek Kopecky" <jacek@...>
      > To: <soapbuilders@yahoogroups.com>
      > Cc: <wsdl@yahoogroups.com>
      > Sent: Friday, December 21, 2001 2:24 PM
      > Subject: RE: [soapbuilders] WSDL soap:binding enhancement for SOAP version?
      >
      >
      > Bob, do you mean the wsdl:arrayType attribute used to specify
      > the type of arrays in XML Schema? I hope we get rid of this
      > extension to XML Schema, and it should be easy as the array
      > attributes are not overloaded now so we can simply use XML Schema
      > default or fixed attribute values.
      > From Systinet's implementation experience handling the
      > wsdl:arrayType extension to XML Schema has been a pain.
      > Best regards,
      >
      > Jacek Kopecky
      >
      > Senior Architect, Systinet (formerly Idoox)
      > http://www.systinet.com/
      >
      >
      >
      > On Fri, 21 Dec 2001, Mike Deem wrote:
      >
      > > A new namespace will allow the schema for array definitions to be
      > > modified to use itemType and arraySize attributes instead of an
      > > arrayType attribute.
      > >
      > > == Mike ==
      > >
      > > -----Original Message-----
      > > From: Jacek Kopecky [mailto:jacek@...]
      > > Sent: Friday, December 21, 2001 8:55 AM
      > > To: soapbuilders@yahoogroups.com
      > > Cc: wsdl@yahoogroups.com
      > > Subject: Re: [soapbuilders] WSDL soap:binding enhancement for SOAP
      > > version?
      > >
      > > Bob,
      > > I also think an indication of the version of SOAP is going to be
      > > necessary.
      > > In my opinion, we have two options here - either an attribute on
      > > soap:binding, or change the namespace of the binding, therefore
      > > taking the new set of elements approach first mentioned by Keith.
      > > I tend to prefer Keith's approach as well, actually, but I'd not
      > > object strongly to the attribute approach.
      > >
      > > Jacek Kopecky
      > >
      > > Senior Architect, Systinet (formerly Idoox)
      > > http://www.systinet.com/
      > >
      > >
      > >
      > > On Wed, 19 Dec 2001, Bob Cunnings wrote:
      > >
      > > > Hello,
      > > >
      > > > While working through implementation issues springing from the
      > > imminent
      > > > arrival of the next SOAP version, I've come to the conclusion that it
      > > would
      > > > be useful if the SOAP version supported by a service could be
      > > specified in
      > > > the WSDL SOAP binding information. In this way a client could
      > > determine
      > > > which version is required in advance of sending a request. If none is
      > > > specified, then the client must guess, but if it is specified,
      > > efficiency would
      > > > be improved (e.g. by avoiding the negotiation involving SOAP 1.2
      > > > VersionMismatch fault messages).
      > > >
      > > > What is proposed here is that the "soap:binding" WSDL extension
      > > element
      > > > have a new attribute defined named "version" with type
      > > "xsd:uriReference"
      > > > (the 2000/10 schema is used in the WSDL spec, it would be "anyURI" if
      > > > 2001 schema was used). The usage would be:
      > > >
      > > > -- if omitted, then no claim is made (there is no default).
      > > > -- if present the value should be a valid SOAP envelope namespace,
      > > i.e.
      > > > "http://schemas.xmlsoap.org/soap/envelope/" for SOAP 1.1.
      > > >
      > > > The soap:binding schema [1] fragment as amended would be:
      > > >
      > > > <...>
      > > > <element name="binding" type="soap:bindingType"/>
      > > > <complexType name="bindingType"> <attribute name="transport"
      > > > type="uriReference" use="optional"/> <attribute name="style"
      > > > type="soap:styleChoice" use="optional"/> <attribute name="version"
      > > > type="uriReference" use="optional"/> </complexType>
      > > > <...>
      > > >
      > > > One possible variation might be to define the type as a URI-list, so
      > > that
      > > > binding supporting multiple versions may list them. Anyway, I thought
      > > > this might be a useful suggestion for the next WSDL version.
      > > >
      > > > RC
      > > >
      > > > [1] http://www.w3.org/TR/wsdl#A4.2
      > > >
      > > >
      > > > -----------------------------------------------------------------
      > > > 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/
      > > >
      > > >
      > >
      > >
      > >
      > >
      > > -----------------------------------------------------------------
      > > 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/
      > >
      > >
      > >
      > >
      > > -----------------------------------------------------------------
      > > 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/
      > >
      > >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
      >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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
      ... 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 2 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 3 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 4 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.