[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [xml-dev] Re: determining ID-ness in XML
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, email@example.com
- Date: Fri, 02 Nov 2001 09:51:55 -0600
First, I'm not a SOAP expert but it was presented as
a reason we couldn't use existing means. Second,
we do have to somewhat ignore the hype and deal
with the technical requirements as best as we can.
If SOAP has no requirements for processing that
requires IDs, then que bueno. We take that off
the requirements stack. If it does, then the
SOAP builders have to be part of this discussion.
What we can't do is simply say, "SOAP won't allow
this" and then ignore standard means because
SOAP did. That is the flaw in the process: if
SOAP does need IDs, the right thing to do was
call for the XML Rec then.
I don't have other than circular technical arguments
here that says DTDs and PIs
cause interoperability problems. That's a red
herring because one can use PIs to put out-of-band
information into the content, and IDs are not
necessarily "typed" information as Henry says.
So that will work. It may not satisfy all
requirements, but since as yet, we don't have
an exhaustive list of those, it is an open question.
IIS vulnerabilities are MS's problem. That is
exactly why some of us say "MS and IE only": because
we can contractually obligate them to fix them.
Who do I contract with to fix SOAP? Again, MS. Why?
They wrote the code I use. What do I do if the fix
is non-compliant? I look at my own requirements
and decide. The point is: I decide. The difference
here is, with the W3C, all I can do is whine. With
MS, I can point to the service agreement and hold
them to it. You can say they will ignore me,
but they won't, at least, not as long as I am
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Yes that is the case. SOAP refusing to acknowledge it
> is a W3C problem. They don't have the authority or perhaps
> the will to make their own specifications interoperable
> and well, so much for their standards.
I'm not sure I follow. First, SOAP 1.2 is not a done deal; it's under
development in public discussions on the firstname.lastname@example.org mailing list.
Anyone who feels strongly that SOAP 1.2 does the world a dis-service by
discouraging DTDs and PIs in SOAP messages is urged to share their reasoning
with the working group. The arguments for keeping out DTDs and PIs are all
ABOUT interoperability; the 99.99% of of Web developers who are not SGML
veterans or conversant with hypermedia theory have found these to be agents
of all sorts of interop problems, and so the various SOAP formulators have
thought best to keep them out of the *subset* of XML that SOAP recognizes.
Counter-arguments -- those that reflect the requirement that SOAP is
intended for communications between all sorts of devices from wristwatches
to mainframes, anyway -- are welcome.
Also, saying that SOAP problems are "a W3C problem" is like saying that
IIS's vulnerability to worms is a Microsoft problem. Literally true, but
not helpful in a world where this stuff is being hyped everywhere, given
away, promoted as the salve for all pain, etc. We complain about the stuff
in Windows or XML that is a "done deal" and all we can do is whine about it.
Since SOAP is not yet a done deal, if you can't live with it, whine now, or
we shall all truly whine later.