Re: XML 1.1 Impact on SOAP

Jacek Kopecky writes:

>> it is my opinion that we should not prohibit the 
>> use of XML 1.1 with SOAP (or the HTTP binding in 
>> particular), even if in some cases there may be 
>> problems.

I can see the value in allowing this, but I remain nervous on several 
fronts:

I think it is a very valuable to have a set of design principle that holds 
for SOAP 1.2 today: 

a) The legal content of a SOAP envelope is the same everywhere, 
independent of node.
b) Every binding specification must provide for moving any such envelope 
from one node to the next (except perhaps in special cases where you know, 
for example, that your binding is used to connect only to a fixed named 
node).

Independent of the HTTP binding, your proposal changes that.  We enter a 
world in which every specification for a header or body must indicate the 
restrictions on its content.  Implementations must take the union of the 
capabilities required and choose an XML format that should be 1.0 in the 
case that no new characters are used in names or content, but 1.1 in the 
case that they are.  That might vary from message to message. 

Now we have a failure mode in which the same message easily transits 3 
hops, but breaks when an intermediary using a header in the new format is 
introduced along with a corresponding binding.  Furthermore, if you do 
what seems best and use XML 1.1 only when truly needed, you run the risk 
that nodes will successfully commincate for weeks or months, then fail on 
a particular message.  Of course, you could go the other way and use 1.1 
unconditionally, which would force the failure earlier.  The downside of 
that is that you'll get lots of messages labeled as 1.1 when in fact they 
could have been 1.0.  It will be a lot of burden on downstream 1.0 
software to get them back in a form that's processable. 

So, I remain nervous about the direction you're suggesting.   Perhaps 
you're right, but I'd like to think through what header specs are going to 
look like, what's going to flow on the wire in realistic scenarios, what's 
going to break when, and whether users will be happy with our choice.  It 
may well be that such an analysis would support your position, but I'm 
reluctant to commit until we've proven it's tractable.  Thank you!


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