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

Yves Lafon writes:

>> You >can< use UTF-8 or UTF-16, but you MUST not.

Please explain.  This sentence I don't understand.  Thank you.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Yves Lafon <[email protected]>
03/31/2004 09:40 AM

 
        To:     [email protected]
        cc:     Herve Ruellan <[email protected]>, Mark Nottingham 
<[email protected]>, "'XMLP Dist App'" <[email protected]>
        Subject:        Re: [XML11TF] (on the "restrictive" option)


On Mon, 22 Mar 2004 [email protected] 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."