Re: [XML11TF] (on the "restrictive" option)

On Mon, 22 Mar 2004 noah_mendelsohn@us.ibm.com wrote:

>
> Yves Lafon writes:
>
> >> Well, the intermediary will have first to understand
> >> a message coming from a binding requiring knowledge
> >> of XML 1.1 (or more) in order to recostruct
> >> the infoset properly.
>
> Agreed.  I guess the reason I see this differently is that failure of two
> nodes to agree on a binding is already an established failure mode in
> SOAP.  Similarly, failure of two nodes to agree on use of one of the
> optional media types or encodings with the HTTP binding is an established
> failure mode.  In the case of the HTTP binding, you can >always< work
> around this by using application/soap+xml and either UTF-8 or UTF-16.

You >can< use UTF-8 or UTF-16, but you MUST not. Also in the MTOM case we
might be in the same situation (part 2, 7.1.4, bullet 2) of not being able
to reconstruct the infoset if MTOM is not understood.

> Having a node that couldn't even store or manipulate the message,
> regardless of the binding you might try to use, seems like a new failure
> mode in SOAP, and that's why it feels architecturally deeper to me.  There

Well to me the main reason of being deeper is the fact that it is a
variability at the top leve of the SOAP exchange, while serialization
details are the latest part. But both are example of variability points
not completely nailed down by the spec.

> is no binding in the world that I could write or acquire that would allow
> me to successfully process an XML 1.1 envelope if my internal node, a
> perfectly conforming SOAP 1.2 implementation, had a DOM, SAX, database or
> other infrastructure  that couldn't handle XML 1.1.  Furthermore, and at
> least as troubling, there is no fallback mode for already-deployed
> instances of the SOAP HTTP binding that would reliably transmit the new
> content, since the only form that (I believe) is mandatory today is XML
> 1.0.  So, those are the reasons that I believe that the XML 1.1 change is

Yes, that's why we need to do something, restrincting at the media type
level to XML 1.0 is the easiest to get the variability at the higher
levels (XML version and infoset in general), while preserving interop of
already deployed services.

So my "vote" is to restrict at the media-type definition level and keep
variability at the infoset level. It gives people the opportunity of
creating a XML1.1-aware binding as well.

In the WSDL case, it might be possible to access the version a tool would
understand using content-negotiation, so the issue is a bit different.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 31 March 2004 09:44:14 UTC