Each of the individual applications using RDF I know of could have been done more easily with plain XML
Absolutely and unapologetically true.
But the statement misses the critical lesson of software architecture (and architecture in general); only by applying constraints can one realize useful properties. RDF/XML based apps have more useful properties than does an XML based app; specifically, “data silos” are avoided.
In a world in which all SOAP messages have <wsa:Action> header blocks, why do my Body elements need XML namespace qualification?
First order answer; I’d say simply because an intermediary that doesn’t know the value of the Action header might want to look at the payload.
Second order answer; I think it’s a fairly small & uninteresting world where it would it make sense to have Action headers within the SOAP envelope. In order for SOAP to make proper use of application protocols (well, transfer protocols at least), SOAP headers should be constrained to containing representation data and metadata, as that’s the data that remains constant between hops over different application protocols. For example, through a HTTP to SMTP bridge, a SOAP envelope should remain constant. “Action” is message metadata, and therefore does not necessarily remain constant between different protocols; it’s hop-by-hop.
Where it would make sense to put the Action header (and other non-representation headers) in the SOAP envelope, is when SOAP is used with transport protocols. But I don’t think there’s much value to that, at least in the short/medium term; the value of reusing established application protocols is too great.
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;
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.
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.
I’m in the middle (or perhaps its the end) of a conversation with Savas Parastatidis regarding a “radical” new form of Web service constraint. Consider his plan to send along this as a message;
<orderForm1> <carOrMotorcycle>car</carOrMotorcycle> <colour>blue</colour> <cc>1800</cc> <model>blabla</model> </orderForm1>
Sure, there’s no symbol visible that can be mapped to an operation, but in order to understand what is being asked of a recipient of that message, something somewhere has to say what is being asked. Otherwise it would inherit the semantics of any underlying application protocol that transferred it – consider that it would mean different things to send it with HTTP PUT and POST – and therefore wouldn’t really be a message, just a piece of a message (representation anyone?).
Based on what Savas explains he wants that message to mean though, what he describes is semantically equivalent to HTTP POST, only without URI targetting, and with an implicit operation rather than an explicit one. I claim that this is a better version of his message;
POST some-uri HTTP/1.1 Content-Type: application/order-form+xml <orderForm1> <carOrMotorcycle>car<carOrMotorcycle> <colour>blue<colour> <cc>1800<cc> <model>blabla<model> <orderForm1>
It’s pretty funny to see pieces of Web architecture being rediscovered by Web services folks. Once the enormity of the big picture of the Web hits home with them, well … let’s just say that there’s a whole lot of walls on which I’d love to be a fly.
BEA CTO Scott Dietzen gave one of those typical Q&A interviews in which he says a lot of the usual stuff you’d expect him, or any Web services proponent, to say about Web services. But he does say something interesting about UDDI;
I took an informal survey of our highest-end customers. We had our top 50 or top 40 end users in a user group together and I was astonished that all of them claimed they had transactional Web services in production and 60 to 70 percent had transactional Web services running between .NET and WebLogic in production. The UDDI[sic] adoption was much less.[sic] People were basically using URIs and URLs as their model for locating and binding into Web services.
and later,
I think it’s also clear that UDDI has been oversold.
Right. So Paul and I were right then?
I think there’s a critically important point being explained here; even in the face of hype-up-the-wazoo, customers will generally opt for simplicity. This is why it is possible for Web services/SOA to fail. All it takes is for customers to understand how to do things the simpler way. The use of URIs and GET is really very simple, so there’s no surprise it was first. Knowing how to use POST and URIs (without operations in the body) is tougher. But it’s just a matter of time before they figure it out, IMO.
A proposal of mine was recently accepted by the RDF Core WG which IMO, will help explain what RDF is for to a lot of people who don’t yet understand the important role it plays in the World Wide Web project. I believe this because I’ve used the RDF it permits, to successfully explain what RDF adds over vanilla XML to Exec types.
Consider the following. Is it XML or RDF?
<Person xmlns="http://example.org/foofoo/"> <name>Mark Smith</name> <age>55</age> </Person>
Answer? It’s both. Depending upon which media type it’s described with, it means different things.
To an XML application that isn’t hardcoded to know about that language, it’s an almost entirely opaque blob, except for the namespace.
To an RDF/XML application that isn’t hardcoded to know about that language, it knows what the XML app knows, plus;
This is the value of partial understanding.
In a report on Web services tools, PC Magazine‘s Robert P. Lipschutz writes;
Data-based strategies such as Roy Fielding’s REST (REpresentation State Transfer) replace SOAP and put the content, Uniform Resource Identifiers (URIs), and XML at the center of the equation. It’s too early to make the call on REST, but don’t rule this option out.