Kudos to Aaron; XML’s deterministic failure model is broken. I agree 100%.

Another sacred cow bites the dust.

Kudos to Kendall Clark for stating XML is Not Self-Describing, as I did last month.

He writes;

Well, I’ve read too much Wittgenstein (not to mention too much Aquinas, Meister Eckhart, and Julian of Norwich) to think that a name is necessarily a self-description

I haven’t read them at all (8-), but I think I have a pretty good understanding of self-description that I developed “Bottom up” during my study of Web architecture over the past few years. As Kendall brought this up again, I’d thought I’d write a few more words about it.

As I see it, description is always with respect to some context. For example, “The sky is blue” is not a self-descriptive statement unless you know;

  • ASCII
  • English
  • Which sky I mean
  • Which colour blue I mean

For any bag-o-bits, it seems to me that there exists a finite amount of contextual knowledge which is necessary in order to be able to understand it. “Self-describing” then, should mean that the bag itself contains sufficient information to identify the required contextual knowledge.

Tim Berners-Lee likes to talk a lot about this. Last year in Honolulu at WWW2002, his keynote was Specs Count, and much of it was about the value in the ability to be able to perform successive application of public specifications in order to understand a message. That’s contextual knowledge, and as you can see in his talk, it doesn’t begin with the HTTP message, it goes all the way down to the IP segment and Ethernet frame; even those bits must be considered (see an example of where this issue can show up in practice).

Where the Web fits in here, is with its contribution of an enormously valuable piece of contextual knowledge; RFC 2396 aka URIs. With respect to the example above, I can use URIs instead of strings, where those URIs can be used to provide the specifics of which blue I meant, by relating it to other colours.

There’s lots to be said about XML, RDF, and why SOA based Web services can never be self-descriptive (hint; too many methods). But I’ll leave it at that for now.

Adam Bosworth sort of lays out some requirements for a “Web services browser”. It’s really funny for me to read this, because I was struggling with exactly these same questions back in 1996 or so, coming from some seriously hard-core CORBA work, but while also being a big fan of what we called the “Universal Front End”; a chunk of software deployed everywhere which could conceivably make use of every service out there. I spent a good amount of time trying to figure out how to integrate CORBA, OpenDoc, and the Web, in an attempt to yield what Adam’s asking for. A couple of years later, I figured it out; the key was the Web’s uniform interface, that you didn’t need to give services service-specific interfaces, you could accomplish the same tasks by exposing the “data objects” (aka resources) of that service via a common set of data-object-centric methods (what Adam refers to as “Add, Delete, Modify”, but which might as well just be GET, POST, PUT, DELETE).

I can even clearly recall holding some of the same misconceptions he had. For example;

Remember, in this dream, a web services browser is primarily interacting with information, not user interface.

Suggesting that today’s Web is about user interfaces. It isn’t, it’s precisely about “interacting with information”, where each information source is provided a URI, and the information is returned on a GET. It pains me to think back to when I didn’t even understand that simple point, because it’s so darned obvious now. But I’m comforted by the fact that gurus like Adam don’t get it, yet. 8-)

Adam earlier mentioned that he was going to be talking about REST. I’m very eager to hear what he has to say about that, given how RESTful his description of a “Web services browser” is. I think he’s almost there.

And BTW, with respect to mobility, I do believe that an additional constraint on top of REST could be useful. I actually wrote up a design at Sun back in 1999 about doing Servlets as Applets, permitting application code to be run in the browser. But Applet integration with the browser was just awful at the time (I think it’s gotten worse since 8-), making this basically infeasible. I should have investigated JavaScript, but didn’t; Mod-pubsub does some of the things with JavaScript that I couldn’t do with Java, in particular intercepting submission of POST data.