Okay, not all the time. If you have to mean what you say the time, life probably gets dull. However, for technical specifications, I suspect that transparency is generally a good idea, and titles should be descriptive.

I'm concluding that Web Services - as represented by SOAP, WSDL, and UDDI, really aren't "of the Web" in any significant way. They've hijacked HTTP for a while, and found a home at the W3C, but they really don't fit.

Why? I'm focusing on two areas, both in SOAP.

The first is what I'll call URI-abuse, where SOAP uses URIs badly on a number of counts. A single URI may represent multiple entirely different kinds of resource to SOAP, effectively depending on what kinds of calls or routing lurk behind that API. WSDL can help you figure out what's where, but there's nothing really natural about it. It's kind of like building a Web site that has only one URL and takes form requests exclusively to figure out what to present you. Yes, you could make that work in HTTP, but it's an alien approach. SOAP developers also seem fond of nearly random URNs for things like namespaces.

The second is a confusion, conflation, or something else between the envelope and the message. SOAP headers are part of the document, optionally part of the MIME headers, or both. While XML lets you do this - you can create elements for whatever you like - it's another practice I can't say I'd encourage. I always had doubts about things like HTML META tags using HTTP-EQUIV. It's a serious blurring between content and delivery system, which feels to me like another wrong turn.

I think the conclusion I'm reaching is that Web Services need a new name, and that they probably don't belong at the W3C, if the purpose of that consortium is to define and develop the Web.

Roy Fielding seemed to come to a similar conclusion yesterday, and Keith Moore and Len Bullard provide more good reasons to think about that today.