Re: R: mistake in SOAP envelope XMLSchema

To hop in on this thread, it seems that both SOAP 1.1 and SOAP 1.2 use 
the namespace http://schemas.xmlsoap.org/soap/envelope/, but the two 
implicitly assume a different XML Schema for that namespace.  Namely, 
SOAP 1.1 (http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) explicitly 
allows the SOAP-ENV:encodingStyle attribute for the SOAP-ENV:Envelope 
element, while SOAP 1.2 prohibits it.  The schema physically retrievable 
at http://schemas.xmlsoap.org/soap/envelope/ applies to SOAP 1.2 only, 
contrary to its comment "Schema for the SOAP/1.1 envelope".  Is there a 
physically retrievable XML Schema for the namespace 
http://schemas.xmlsoap.org/soap/envelope/ that applies to SOAP 1.1?

Scott Nichol

----- Original Message ----- 
From: "Christopher B Ferris" <chrisfer@us.ibm.com>
To: "Alessandro Pira" <apira@kion.it>
Cc: <xml-dist-app@w3.org>; <xml-dist-app-request@w3.org>
Sent: Wednesday, November 14, 2007 12:31 PM
Subject: Re: R: mistake in SOAP envelope XMLSchema


Ah, clearly I misunderstood your request.

As for SOAP1.1, that specification, nor it's schema is maintained by the
XML Protocol WG. The WS-I
Basic Profile [1], however, aligns with the direction that the XML
Protocol WG took in disallowing use of the
soap:encodingStyle attribute on the soap:envelope element:

R1005 An ENVELOPE MUST NOT contain soap:encodingStyle attributes on any 
of
the elements whose namespace name is
"http://schemas.xmlsoap.org/soap/envelope/".

Since the WS-I Basic Profile is followed by most implementations, since 
it
helps to improve the interoperability of those
implementations, it seems to me that any change to the SOAP1.1 schema is
also unnecessary.

[1] http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html

Hope this helps,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 234 2986

xml-dist-app-request@w3.org wrote on 11/14/2007 09:48:17 AM:

>
> Hi Christopher,
>
> thank you for your answer.
> Actually I was talking about SOAP 1.1 (not 1.2) and about this
XMLSchema:
>
> http://schemas.xmlsoap.org/soap/envelope/
>
> which (as stated in the comment) appears to be the official SOAP 1.1
> schema. (Am I wrong?)
> I agree with you: SOAP 1.2 does not allow the encodingStyle
> attribute to appear on the envelope element, but SOAP 1.1 (and its
> schema) should!
>
> Best regards,
>
> Alessandro Pira
>
>
> Da: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Inviato: mercoledì 14 novembre 2007 15.07
> A: Alessandro Pira
> Cc: xml-dist-app@w3.org
> Oggetto: Re: mistake in SOAP envelope XMLSchema

>
> Alessandro,
>
> The quoted text you cite is pretty clear. I have emphasized using 
> CAPS.
>
> "SOAP 1.2 DOES NOT ALLOW the env:encodingStyle attribute to appear
> on the SOAP env:Envelope, whereas SOAP 1.1 allows it to appear on
> any element. SOAP 1.2 specifies specific elements where this
> attribute may be used."
>
> Additionally, from the SOAP1.2 specification [1]:
>
> "The encodingStyle attribute information item MAY appear on the
following:
> 1.        A SOAP header block (see 5.2.1 SOAP header block).
> 2.        A child element information item of the SOAP Body element
> information item (see 5.3.1 SOAP Body child Element) if that child
> is not a SOAP Fault element information item (see 5.4 SOAP Fault).
> 3.        A child element information item of the SOAP Detail
> element information item (see 5.4.5.1 SOAP detail entry).
> 4.        Any descendent of 1, 2, and 3 above.
> The encodingStyle attribute information item MUST NOT appear on any
> element other than above in a SOAP message infoset."
>
> The soap:encodingStyle attribute is NOT permitted to be included in
> on the soap:Envelope element. Therefore, the schema is correct.
>
> [1] http://www.w3.org/TR/soap12-part1/#soapencattr
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
> phone: +1 508 234 2986
>
> xml-dist-app-request@w3.org wrote on 11/12/2007 05:44:25 AM:
>
> > Hi all,
> >
> > I am writing to this mailing list since I think I found a mistake in
> > the official xml schema for SOAP envelopes:
> >
> > http://schemas.xmlsoap.org/soap/envelope/
> >
> > The error involves the encodingStyle attribute which (as stated in
> > examples in the note and also in [1]) seems possible to use in the
> > Envelope element.
> > But the official XMLSchema 
> > (http://schemas.xmlsoap.org/soap/envelope/
> > ) forbids this since it states:
> >
> > [...]
> > <xs:complexType name="Envelope">
> >  <xs:sequence>
> >    <xs:element ref="tns:Header" minOccurs="0"/>
> >    <xs:element ref="tns:Body" minOccurs="1"/>
> >    <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"
> > processContents="lax"/>
> >  </xs:sequence>
> >  <xs:anyAttribute namespace="##other" processContents="lax"/>
> > </xs:complexType>
> > [...]
> >
> > I think it should say namespace="##any" in the xs:anyAttribute
> > element (or explicitly define the encodingStyle attribute).
> >
> > I wrote you because the company I work for publishes some
> > webservices for our customers, and we use 3rd party libraries for
> > managing SOAP communication. Now some of our customers for some
> > reason are accusing us to be not compliant to the official SOAP
> > protocol, which I think is not true, but even W3C XMLSchema
> > validator shows that the Envelope we use is not valid because of the
> > "encodingStyle" attribute.
> >
> > Can you please check if it's possible to correct the XMLSchema?
> >
> > Thank you in advance for your time,
> >
> > Alessandro Pira
> >
> >
> > [1] : the SOAP 1.2 part 0 Primer in Chapter 6 (Changes Between SOAP
> > 1.1 and SOAP 1.2) states:
> >
> > "SOAP 1.2 does not allow the env:encodingStyle attribute to appear
> > on the SOAP env:Envelope, whereas SOAP 1.1 allows it to appear on
> > any element. SOAP 1.2 specifies specific elements where this
> > attribute may be used."
> >
> >

Received on Friday, 16 November 2007 11:23:22 UTC