Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@S...] > 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@w... 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.
|
