RE: [xml-dev] Re: determining ID-ness in XML

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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

len

-----Original Message-----
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 xml-dist-app@w3.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.