| Newsgroups |
gmane.text.xml.distributed |
| Message-ID |
<[email protected]> |
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
--------------------------------------