Well, those new specs sure got a thorough thrashing, although perhaps indirectly. Tim Bray and Sean Mcgrath sum it all up for me, as usual.

<html xsl:version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns="http://www.w3.org/TR/xhtml1/strict">
  <head>
    <title>Expense Report Summary</title>
  </head>
  <body>
    <p>Total Amount: <xsl:value-of select="expense-report/total"/></p>
  </body>
</html>

(reference)

Update; ok, for the two of you that missed my point, that document is both an XHTML document and an XSLT 1.0 stylesheet. All the root namespace tells you is, well, the root namespace. The actual type is orthogonal to this, and in fact, orthogonal to anything in the document itself. Unless we want to prevent this form of compound document from being used, it is critical that media types continue be the key from which applications are dispatched.

As previously suspected, it seems WS-Transfer is missing POST because of an attempt to limit it to CRUD semantics. From the latest MS whitepaper;

A factory is a Web service that can create a resource from its XML representation. WS-Transfer introduces operations that create, update, retrieve and delete resources.

That’s one possible interpretation, arguably reinforced by Don’s post.

Feel the love!

It’s been a long time coming, but the Web services stack finally catches up to where the Web was 15 years ago, and where email was 20 years before that; exchanging documents over the Internet. Happy days! <groan/>

Facetiousness aside though, it’s unfortunate that the layering is still so butchered; WS-Transfer just reinvents HTTP on top of SOAP on top of HTTP. And for what exactly? They could have just reused HTTP’s methods which are already outside the envelope, the way most people use application protocols, and still get all the goodness of SOAP. Who the heck wants to try to bootstrap a whole new Web when the one we’ve got is doing just fine, thank-you-very-much?

It’s also curious that POST is missing, yet CREATE has been added. This seems an obvious attempt to equate the uniform interface with CRUD, but it’s unclear whether that’s to try to restrict the range of possible applications WS-Transfer could be used for, or because the authors honestly thought nothing was being lost with this omission? Knowing many of the authors, I bet the latter, but who knows …

As interesting as this is to see though, I don’t see anybody choosing to use it over vanilla HTTP or RESTful SOAP+HTTP. I’d be interested in anybody’s thoughts who disagreed with me on that.

Run away!
(link) [del.icio.us/distobj]
Googles for images, converts to ascii art using only the search word. Funky. Integration of distributed components, REST-style.
(link) [del.icio.us/distobj]

Try searching Google for “soap rest” What’s interesting isn’t the results, it’s the sponsored link; a pointer to an opening on the Google team.

Similar searches for “soap java” and “soap” don’t show the same link.

Hmm, I wonder what prompted that? Or maybe I just don’t understand how AdWords works.

Kudos to Dave for pulling up his socks and discovering what Semantic Web technologies have to offer first hand – you know, all that wonderful extensible goodness I’ve been going on about after discovering it for myself.

He talks about a perceived problem here …

In order to prevent an area code, I need to add the area code with a cardinality of 0. Now I think this is a pretty big problem. The whole Semantic Web world view of open content models comes and bites us here. The rough assumption is that if a property isn’t specifically exluded, it might be related to the thing.

That’s not quite right. It’s one thing to look at the information space that is the Web/Sem-Web and see two separate but related resources (e.g. the PO and the customer), but it’s something else entirely to look at a message on the Web and conclude that there might be some data elsewhere which is intended to be communicated. That’s where self-description comes in, and it prescribes that if a message arrives with a PO and without a customer, then the customer information is not part of the message, as you require. What Bijan seems to be talking about is the former, not the latter, i.e. to avoid closed world assumptions.

He adds;

If we think of the main point of a schema language as defining the language for exchanging information, it seems that RDF/OWL is a easier to use for extensibility and versioning. Which might be no surprise given the design centres. But given the inability to control the schemas in all the right facets – such as mandatory extensions – it doesn’t fully solve the problems of large scale distributed system extensibility and versioning. More work to be done….

…which is true, I think there is more work to be done (though I also think what’s done is a decent 80-90% solution, just as HTTP is despite not having mandatory extensions). More on mandatory extensions and RDF later though; I’ve given this subject a lot of thought (and code) over the past couple of years.

P.S. I think it’s really interesting that Web services proponents are discovering the virtues of the Semantic Web before they really appreciate all the Web itself has to offer. I totally didn’t see that coming! Coincidentally, check out this message (lists.w3.org is having issues right now, stay tuned…) where an OWL-S user realizes some of the problems with the Web services model.

From Paul Krill, on the topic of Web services;

There must be a way to simplify all this because it surely is going to be a tough task for vendors and enterprises to support all this complexity in the name of simplificity[sic]

There is a way, Paul. A stack built upon the Web itself.