If you look back at all of my postings, I've consistently recommended that we explore new and better ways to do web services, but not at the expense of the current set of technologies. My customer base (12,000+ registered users) loves SOAP -- very possibly because the RPC/Messaging semantics are familiar and comfortable. If the "Web architecture" is such a *very* difficult thing to understand, perhaps that's why most users don't feel particularly concerned that SOAP doesn't conform. Things that are *very* difficult to understand generally don't achieve wide adoption. On the other hand, SOAP has been experiencing extraordinary success (even though Mark refuses to acknowledge it). Even so, SOAP 1.1 is flawed (incomplete, imprecise, etc. -- not "bad technology"), and it needs revision. We need SOAP 1.2.

The reason I spoke up at this time is that it appeared apparent to me that this Unsafe Methods finding would provide a convenient excuse to allow the TAG to challenge the release of SOAP 1.2 as not "web-friendly". My immediate goal (speaking for my customers, not for my *small* company marketing machine) is to improve the current Web Services architecture -- to improve SOAP and WSDL, and to define standard SOAP extensions to support interoperable security, routing, attachments, and conversations.

Not that it matters, but I've never been overly found of the name "Web services", because Web services (based on the existing Web services architecture) aren't constrained by Web technologies. A more accurate name would be "network services" or "XML application services". A Web service can just as effectively communicate over MQSeries, Jabber, or WAP. Although an HTTP binding is required, SOAP uses HTTP strictly as a transport (not as an application protocol), and SOAP is inherently transport-independent. (Hence our dispute.)There are only two Web-oriented requirements in the current Web services architecture: a Web service is identified by a URI, and it uses XML messaging. But Microsoft named them "Web services", IBM endorsed the name, and that was that. The name stuck, for better or worse.

I have a question for Roy: If you believe that SOAP is such "bad technology", why do you condone not one, but two, SOAP projects at Apache?

And I have a question for the TAG: If so many members of the TAG viewed SOAP 1.1 as such "bad technology", why did it launch a Working Group with such a restrictive charter that mandated that XML Protocol be based on SOAP 1.1? Based on this new Web Architecture now being defined, I would say that the XML Protocol charter is self-contradictory.

I encourage Mark, et al, to develop technologies and products that implement Web services in a Web-friendly way, and market them to the public. I advise you to figure out a way to explain the Web architecture so that the average Joe can grok it and appreciate why it is so much better than SOAP. Then, perhaps, this new approach to Web services will gain comparable public adoption as SOAP has to date.

But first let's release SOAP 1.2. Either that, or let's be upfront and let the members know that W3C is not the right venue to advance this technology. I'm sure we can take our work someplace else.

Best regards, Anne