Here I was, working on a rambling retort to Clay, when Sam nails it;
Two parts brilliance, one part strawman. Pity, actually, as I am sympathetic with the point that Clay is trying to make.
Rest assured, this “problem” isn’t unknown to Semantic Web folk. It’s actually an
official TAG issue,
goes by the moniker “public meaning”, and has its very own
task force
to tackle it (and unlike other task forces, they’re actually making progress!).
FWIW, my view (explained partially here)
is that although this is another one of those
unmaskable problems in distributed systems,
that doesn’t mean there’s not a way forward.
Consider the HTTP 404 response code. I see it as a boundary case of the public meaning
issue, where ambiguity is maximized due to having no available information from
which to infer meaning, leaving public meaning to be determined solely by use, just as with
Clay’s “People” example. But did the Web stop working because of 404? Of course not.
404 is a feature, not a bug, as Clay himself
observed.
The Web works “despite” 404, because there’s public value in not using it, just
as there’s public value in being as unambiguous about URI semantics as need be.
Will there be ambiguity on the Semantic Web? Of course. You still get 404s, right?
Don’t get hung up on the “object” there; it’s a logical view.
The picture is meant to capture the essence of what I see as the
fundamental misunderstanding/mistake of Web services. This
misunderstanding goes by several names;
- transport vs. transfer;
transfer gets you all the way to the business logic, while transport only gets you as far as the interface.
- tunneling
- uniform vs. specific interfaces
- late binding; an identifier is sufficient to get you direct access to the state & logic
- a priori information;
see late binding; deployed agreement on HTTP & URIs suffices
When I hear “application integration”, I’m thinking the bottom picture, not the top,
because APIs just get in the way.
Don Box
responds
to Jon Udell regarding XAML. He writes;
XAML is just an XML-based way to wire up CLR types – no more no less.
That’s not how XAML comes off at all. In the examples, there are
names such as “TextPanel” and “Heading” in the XAML namespace; those
aren’t the sort of things I’d expect in a binding language.
But if the examples are just misleading, and Don’s statement
is taken at face value, what XAML would actually be aiming to replace
isn’t HTML/CSS, it’s RDF/RDF-Schema;
<Object def:Class="MyClass" />
is essentially equivalent to;
<my:MyClass>
<rdfs:subClassOf rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Resource"/>
</my:MyClass>
Hmm.
Over the weekend, I found a great
article
by Steve Loughran on the impact of
Sitefinder
on Web services tools. It’s very well written, and covers the entire space.
I was particularly impressed by the indepth analysis of the issues regarding
BCP 56 (aka RFC 3205)
“On the use of HTTP as a Substrate”, which Verisign used to
defend its position.
Steve saw right through that, which is easier said than done; there’s a lot of
subtlety there, as the
XML Protocol WG response
to the IESG (which I co-authored) describes.
Norm asks;
Given a random XML document, one of the things you might want to know about it is, “What is an appropriate schema to apply”? Now, for DTDs, this is a simple question: look at the document type declaration. If it has one, the public and system identifiers will tell you what DTD to apply; if it doesn’t have one, there’s no DTD to apply.
Sounds like a job for RDDL.
A good and seemingly fair
comparison
of different approaches to using
Amazon Web services
in PHP, via SOAP and REST.
I’d previously heard
Tim O’Reilly’s 85% number
(relayed via Jeff Barr), but
just learned of another interesting stat in that article; Amazon’s RESTful
queries (via GET) are 6x faster than their non-RESTful ones (via POST). That
seems high to me, but not having any more details in front of me, it’s hard to
dissect why that might be the case. Anyone got the details?