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

WSDL soap:binding enhancement for SOAP version?

Expand Messages
  • Bob Cunnings
    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
    Message 1 of 13 , Dec 19, 2001
    • 0 Attachment
      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
    • Keith Ballinger
      I ve been thinking about this as well. I tend to think that a better approach would be to create a new set of tags in a different namespace to indicate SOAP
      Message 2 of 13 , Dec 19, 2001
      • 0 Attachment

        I’ve been thinking about this as well. I tend to think that a better approach would be to create a new set of tags in a different namespace to indicate SOAP 1.2. This would allow for a cleaner separation. Also, if SOAP 1.2 requires new attributes in the binding, or the lack of old information from the old binding, it would less ambiguous.

         

        -----Original Message-----
        From: Bob Cunnings [mailto:cunnings@...]
        Sent: Thursday, December 20, 2001 1:45 AM
        To: wsdl@yahoogroups.com
        Cc: soapbuilders@yahoogroups.com
        Subject: [soapbuilders] WSDL soap:binding enhancement for SOAP version?

         

        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 the Yahoo! Terms of Service.
      • Bob Cunnings
        Hello, This has merit as well, if one wants to indeed force a clean separation between bindings for SOAP 1.1 and SOAP 1.2. I expect that many implementations
        Message 3 of 13 , Dec 19, 2001
        • 0 Attachment
          Hello,

          This has merit as well, if one wants to indeed force a "clean separation"
          between bindings for SOAP 1.1 and SOAP 1.2. I expect that many
          implementations will transparently support both envelope versions for the
          same service, so it might be more convenient to retain the existing WSDL
          binding extensions and publish only one binding, rather than two. A lot
          depends on the degree of compatability between the SOAP versions. It will be
          interesting to see how it all works out.

          RC

          I've been thinking about this as well. I tend to think that a better
          approach would be to create a new set of tags in a different namespace
          to indicate SOAP 1.2. This would allow for a cleaner separation. Also,
          if SOAP 1.2 requires new attributes in the binding, or the lack of old
          information from the old binding, it would less ambiguous.

          -----Original Message-----
          From: Bob Cunnings [mailto:cunnings@...]
          Sent: Thursday, December 20, 2001 1:45 AM
          To: wsdl@yahoogroups.com
          Cc: soapbuilders@yahoogroups.com
          Subject: [soapbuilders] WSDL soap:binding enhancement for SOAP version?

          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




          Yahoo! Groups Sponsor


          ADVERTISEMENT

          <http://rd.yahoo.com/M=178320.1681224.3270152.1261774/D=egroupweb/S=1705
          701014:HM/A=879172/R=0/*http:/www.fastweb.com/ib/yahoo-75f>


          <http://us.adserver.yahoo.com/l?M=178320.1681224.3270152.1261774/D=egrou
          pmail/S=1705701014:HM/A=879172/rand=929598948>

          -----------------------------------------------------------------
          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 the Yahoo!
          <http://docs.yahoo.com/info/terms/> Terms of Service.
        • Jacek Kopecky
          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,
          Message 4 of 13 , Dec 21, 2001
          • 0 Attachment
            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/
            >
            >
          • Mike Deem
            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
            Message 5 of 13 , Dec 21, 2001
            • 0 Attachment
              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/
            • Jacek Kopecky
              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
              Message 6 of 13 , Dec 21, 2001
              • 0 Attachment
                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/
                >
                >
              • Andrew Layman
                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
                Message 7 of 13 , Dec 27, 2001
                • 0 Attachment
                  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/
                • ashish ranjan
                  Are there any soap libraries designed for applet? When i use apache recommended library to build a applet based client for a webservice i get security
                  Message 8 of 13 , Dec 27, 2001
                  • 0 Attachment
                    Are there any soap libraries designed for applet?

                    When i use apache recommended library to build a applet based client for a
                    webservice i get security exceprion as tthe program tries to read
                    jaxp.properties file....

                    What is the workaround of this problem?

                    Ashish
                  • Jan Alexander
                    Hi Ashish, you can try our WASP server, which has support for running as an applet. Please see http://www.systinet.com/products/ for more details about WASP
                    Message 9 of 13 , Dec 28, 2001
                    • 0 Attachment
                      Hi Ashish,

                      you can try our WASP server, which has support for running as an applet.
                      Please see http://www.systinet.com/products/ for more details about WASP
                      editions and documentation of the particular WASP edition for more
                      details about running WASP as an applet (for example WASP Lite
                      documentation is located here:
                      http://www.systinet.com/products/wasp_lite/doc/index.html).

                      Sincerely,

                      Jan Alexander
                      WASP Server Project Leader, Systinet (formerly Idoox)
                      http://www.systinet.com

                      ----- Original Message -----
                      From: "ashish ranjan" <aranja01@...>
                      To: <soapbuilders@yahoogroups.com>
                      Sent: Thursday, 27 December, 2001 19:58
                      Subject: [soapbuilders] SOAP library for APPLET


                      >
                      > Are there any soap libraries designed for applet?
                      >
                      > When i use apache recommended library to build a applet based client
                      for a
                      > webservice i get security exceprion as tthe program tries to read
                      > jaxp.properties file....
                      >
                      > What is the workaround of this problem?
                      >
                      > Ashish
                      >
                      >
                      > ------------------------ Yahoo! Groups
                      Sponsor ---------------------~-->
                      > Send FREE Holiday eCards from Yahoo! Greetings.
                      > http://us.click.yahoo.com/IgTaHA/ZQdDAA/ySSFAA/W6uqlB/TM
                      > ---------------------------------------------------------------------~
                      ->
                      >
                      > -----------------------------------------------------------------
                      > 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/
                      >
                      >
                    • 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 10 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 11 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 12 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 13 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.