Re: XML 1.1 Impact on SOAP

Jacek Kopecky writes:

> 
> Noah, 
> 
> I think I understand your position. 

Good, and I think I understand yours too.

> 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.

Understood
 
> [...] 

> 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?

My problem is that I see a third:

3) We allow XML 1.1 as you suggest.  Some SOAP
   implementations support it but older ones
   don't (we're already a REC, after all).
   We can point to lots of fine print in
   the specs that say everyone is conformant,
   but customers discover that different SOAP
   implementations only work with each other 
   some of the time.  Instead of the new
   world of Web Services where they have
   reasonable expectation of interop across
   vendors, they start assuming things
   only work from a single source.  We
   had that with Corba and DCOM. 

Also, even vendors that might want to move up may find it difficult. 
Potentially every level of your XML stack has to deal with those new 
element names and content.  You have an old version of some API or tool, 
it's going to be hard to move.  Do you store your data in an XML store 
that you bought last year?  Even if your SOAP stack is upgraded, what are 
you going to do with that new form data.  Do you have a version of XML 
Schema that you can put in a version of WSDL to describe those new 
messages, and do the string types in your version of schema validate the 
new control characters?  I think there are lots of pieces to be lined up 
to get the whole stack working with these new features of 1.1.  (BTW:  I 
will probably be giving a 3 min "lightening talk" at the plenary laying 
out some of these issues, in the hopes of starting cross-wg discussions.)

As so often happens, I tend to be pretty far over on the side of:  SOAP is 
about universal interop, and the expectation of universal interop, even at 
the occasional expense of slower migration to new function.  If I thought 
everyone had the software in place to do 1.1 easily and all we needed to 
do was to add it to the first WS-I profile for SOAP 1.2, I'd be more 
enthusiastic.  As it is, I think it would be hard for certain vendors and 
software environments to make the switch even if they wanted to. 

For the record, I'm not coming down 100% against doing this now, just 
asking that we take a long hard look at it before deciding.  Particularly 
in the case of the element names, I understand there are parts of the 
world where the new characters will be handy, at least occasionally.  On 
the other hand, SOAP is for machine-readable messaging, and it already 
supports the rather large set of element names allowed by XML 1.0.  I 
wonder whether that's too great a limitation over the next 2-5 years if in 
return we get off the ground with more universal interop.

> Best regards,
> 
>                    Jacek Kopecky
>                    Systinet Corporation
>                    http://www.systinet.com/


...and to you!

Noah

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

Received on Monday, 16 February 2004 21:58:25 UTC