Re: XML 1.1 Impact on SOAP

Noah, 

I think I understand your position. I've always viewed the situation in
the opposite way: I thought it was *not* our intention to restrict SOAP
to XML 1.0, and if such restrictions were inadvertently introduced
(which could really only be verified after XML 1.1 was in place), they
should be removed.

There are incompatibilities between XML 1.0 and XML 1.1, that's of
course why the version number has changed. Certainly, these problems
were carefully weighed before XML 1.1 was introduced. 

Currently, no WS spec I know uses non-US-ASCII characters in element
names, but also no WS spec I know explicitly puts any XML-1.0-related
restrictions on the extensibility elements or the payloads. The legal
content of a SOAP envelope is the infoset, is that tied specifically to
XML 1.0? I don't think so.

I think the general principle should be that a spec layered on top of
another spec should not restrict the underlying layer just because of
possible problems that occur only on that layer. 

If XML 1.1 dropped attributes, SOAP would rightfully restrict itself to
XML 1.0 because it uses attributes (mU, role etc). Since SOAP itself is
unaffected by XML 1.1, it shouldn't care about it.

I see two possible outcomes here (the others I view, with no hard
backing material, as extremely unlikely):

1) XML 1.1 capabilities will prove virtually unused (not necessarily
useless), people will do without them, world continues with XML 1.0.

2) XML 1.1 capabilities will prove useful, people start using them,
developers just shrug and add XML 1.1 support, world slowly and mostly
painlessly moves to XML 1.1. Should we then have to introduce a new
version of SOAP (or of a part of it) to handle XML 1.1?

Best regards,

                   Jacek Kopecky

                   Systinet Corporation
                   http://www.systinet.com/




On Thu, 2004-02-12 at 20:18, noah_mendelsohn@us.ibm.com wrote:
> 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
> --------------------------------------
> 
> 
> 
>

Received on Friday, 13 February 2004 09:35:14 UTC