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

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.

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 
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 
architeturally deeper than the lattitude we today allow in on-the-wire 
formats for the SOAP HTTP binding.  We can discuss on the call in a few 
minutes.  I hope I haven't missed something important in your argument.

Thank you!

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

Received on Monday, 22 March 2004 10:44:25 UTC