Web Things, by Mark Baker

“It’s pretty clear to me that the RDF data model is simpler”. See, there is hope for BEA.
(link) [Mark Baker’s Bookmarks]

Sean discovers WS-MessageDelivery which triggers him to display a level of frustration that I didn’t expect to see, but that I’m happy about. We need more integration gurus to raise their hands and ask “Hello, what the $%@! are you people doing?!”, in the hope that those building this architecture may stop to take the time to think about what they’ve created and give it the principled architectural examination it requires. Sean writes;

You started at the wrong end of the pipe. SOAP always was and always will be and API-centric worldview. That is not the future. That is the past. Re-implemented badly. Sometimes I wonder. I really do.

I disagree that SOAP requires an API-centric worldview – I battled against enormous odds to ensure SOAP 1.2 didn’t – but I certainly agree that this is how Web services proponents and specs are using the SOAP specs.

On the other hand, to their credit, Web services promoters are trying to distance themselves from APIs. The problem is that they think they’ve done this with “document oriented SOAP” by removing the operation from the message. Unfortunately though, in their architecture, the operation is still in effect, it’s just hidden from the message which actually makes things worse than RPC (in case you wondered if that was possible!).

What Web services need is an architecture based purely on document exchange, not some RPC/document bastard. Luckily, one is readily available.

Good stuff from Lucas. IMO, a URI would be better than a bit, but I’d much prefer an RDF document to the URI, so that all that information could be in the stream itself.
(link) [Mark Baker’s Bookmarks]

“Make the operations of your web service interface as granular as possible.”. Unfortunately, the quality of the advice given in the rest of the article isn’t quite so good.
(link) [Mark Baker’s Bookmarks]

First Bosworth, now Dietzen. Mnot for CTO!!
(link) [Mark Baker’s Bookmarks]

A very cool and intuitive Python API for HTTP by Mark.

On a related note, being a command-line kinda guy, I’ve long lusted for a “Web shell” which allows me to do this (but lacked the time or skill necessary to build my own);

$ cat  http://example.org/some-uri # PUT
$ cat foo >> http://example.org/some-uri # POST
$ rm http://example.org/some-uri # DELETE

Idea courtesy Jeff Bone

Phew, that took longer than expected! Congratulations to Roy and the adhoc “URI WG”.

Norm continues the slagging of the XML serialization of RDF, RDF/XML.

So, since somebody’s gotta do it, I’ll put my neck on the line by saying that I really don’t have any big problems with RDF/XML.

For me, RDF/XML works because it makes the simple things simple. Consider the following document;

<Person xmlns="http://example.org/foofoo/">
  <name>Mark Smith</name>
  <age>55</age>
</Person>

IMO, if the serialization can’t support extracting the same triples as a human would intuitively expect to be there, then it’s broken, or at least not suitable for hand-authoring (which I’ve had no problems doing).

Yes, that’s simple, but I’d say it’s about 70% of what I do with RDF, and I’d expect that for many people, it’s probably at least 50% of what they do with it.

And yes, striping is a nuisance some times. And lists and collections are annoying. And don’t get me started on reification. But the simple stuff is simple.

Actually, I should come clean and say that despite my claims above about not having any problems with RDF/XML, I have had some. But you know what? The problems I’ve had are always with XML. XML is just a really sucky syntax for lots of network-centric things I do, thanks to its seemed-like-a-good-idea-at-the-time deterministic failure model. This is what requires you (unless you want to institute transaction semantics between your app and parser, uh huh) not to do any application processing until you’ve received the final “/>”; because you never know, it might not arrive, and it’s only then that you realize “Oopsie!”, that wasn’t XML after all. Streaming? By definition, impossible. Latency-sensitive apps? Forget about it!

I’m overstating the case, of course. I use XML, a lot. It’s the default syntax that my last project used on the wide open Internet due to its pervasive recognition and support. We also used it as the default output format for our embedded systems, since producing it is cheap. But for embedded consumption, and between instances of our own software, we use Turtle.

Wow, what’s the record for most minority opinions on one W3C TR? Three were submitted today.
(link) [Mark Baker’s Bookmarks]

I got a couple of comments on the diagram, so patched it up.