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.

Jim Webber posted a picture in an earlier blog entry that I’ve tweaked to reflect my views of large scale software architectural evolution (or lack thereof 8-) over the the past 10 or so years.

The differences with Jim’s can be explained thusly;

  • Though REST wasn’t published until 2000, the major architectural work behind the Web, as I understand it (can’t find the message from Roy where I thought I recalled him saying this), was basically wrapped up in 1993
  • I consider document based RPC – i.e. same semantics as RPC, only without the operation in the message – to be worse than RPC
  • As much as I prefer “processMessage” to what most people know “SOA” to be, I still consider it inferior to REST, since it’s missing an application model (REST has hypermedia), as well as layering (or perhaps I just need a more detailed breakdown of the constraints of a processMessage-oriented architecture)
  • The Semantic Web and ARRESTED are extensions built upon the Web and REST. I believe that these will be the future of loosely coupled, document oriented services offered and integrated over the Internet
Interesting report which includes some of their ideas on PVR UI design
(link) [Mark Baker’s Bookmarks]

My deep thought for the day …

Evolvability is a special case of integrability, where one integrates over time rather than space.
Whither WHAT?
(link) [Mark Baker’s Bookmarks]

Via Jim McGee, a quote from an idol of mine, David Gelernter;

Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity.

Amen.

That’s the ticket.
(link) [Mark Baker’s Bookmarks]
Which reminds me, I still have some invites left if anybody wants one.
(link) [Mark Baker’s Bookmarks]