Sam Ruby implements the
RSS Trackback module in his RSS 2.0 feed. It’s implemented by simply
including a “trackback:ping” qualified URI in the item. For the item
that corresponded to his
announcement of
support, the URI is;
http://www.intertwingly.net/blog/1105.tb
So being the Web-head that I am, I invoked GET on it. Here’s what I saw;
<?xml version="1.0" ? >
<response>
<error>1</error>
<message<excerpt not found</message>
/<response>
I note that Paul,
Ben, and Mena had written about
what could be returned,
which is bang on from my POV, though you could also include the number
of received pings in there, which could be useful, and make a nice link from the
human-readable blog.
Just thinking out loud; I’m not trying to put more work on Sam’s plate 8-).
Congratulations to the XML Protocol WG.
The end is near! 8-)
I’ve got to agree with Sam
and CNet.
I just can’t get too excited about Office 11 and its XML support.
XML is syntax, a context free grammar. Standardized syntaxes are
wonderful, but heck, it’s just syntax. And while a published
schema would describe some data semantics, it would still leave loads of wiggle
room for the format to remain proprietary.
I think it is useful, as it does open up the format to XML tools
like XSLT. But any use of tools with the Office XML format (such as
XSLT style sheets written to manipulate it) will be locked-in to the
Office 11 format, the same way that software written to the Win32 API
is locked-in. That’s not an inherrently bad thing, of course, but
let’s call a spade a spade.
Dave Winer says;
SOAP and XML-RPC were started to make it easy to build applications that viewed the Internet as if it were a LAN.
which is 100% true, and at the same time, 100% the wrong thing to do. The Internet is not a LAN. On a LAN, there’s one administrative/trust domain, and on the Internet there’s, well, a whole lot more than one. Computing in those two domains – LAN and Internet – is not the same thing, and therefore requires different solutions (though arguably it could be said that the LAN is a special case of the Internet, where number of trust domains = 1, so what works for the Internet could also work on a LAN – but the converse obviously doesn’t hold).
And for the record Dave, I write software, thank you very much (and so does Paul). Not as much as I used to, but I still do, and still enjoy it (especially now that I’ve switched to Python from Java). It’s all too easy to put down a detractor rather than trying to understand what they have to say, I suppose.
So quoth Dave Winer;
After all these years, I’ve concluded that if I can’t understand it, it doesn’t have much of a chance in the market.
Well, without taking potshots at Dave, I think this is a fairly poor way to judge a technology. The interaction of a technology with its users is an incredibly complex environment that has no single metric that can indicate the success or failure of that technology. But what I look for in any technology, is network effects.
I haven’t talked much about RDF or the Semantic Web in my blog yet, so I’ll just say
a quick word about them.
The Semantic Web is the Web with an additional
architectural constraint
that could be called “Explicit Data Semantics”; that data (representations, in the
case of the Web) will be constrained to be explicit about its implied semantics.
This adds the additional desirable property to the system of
partial understanding.
In a nutshell, this basically means that you get to avoid the “schema explosion”
problem, where you have a bazillion different XML schemas, and understanding them is an
all or nothing proposition (i.e. where software only understands the schemas it was
programmed to understand). RDF and the Semantic Web doesn’t change one important thing;
software will not “know” anything more than it was programmed to know. But it does allow a
single piece of software to be able to do whatever it is that it does, on any data
anywhere. For example, I could write software that
searched for “people”, and it could find references to “people” in many different XML
documents if RDF were used. And that generates network effects up the wazoo.
Jon Udell writes that Groove has a REST interface, which peaked my interest. We’re discussing it over on rest-discuss.
I’m very encouraged to hear about REST being considered a cool and useful thing, and thank Jon for pushing that position. But (you knew this was coming, didn’t you? 8-) it doesn’t sound like Groove has it quite right. The bit of Jon’s article that suggested this to me was this;
It’s all organized as a web of linked XML documents controlled by a handful of verbs such as Create, Read, Update, and Delete.
It is true that a pre-defined set of small methods will help the system immensely, because coordination costs are lowered, and visibility is increased to firewall administrators (at least when the specification of its semantics are specified in the open, or just standardized). But not every set of fixed methods means you have a RESTful interface. As I described on rest-discuss, the uniform interface constraint also has something to say about which methods you use. Specifically, it says that any method you use must be usable on all resources/objects/services/whatever. Like GET, PUT, POST, DELETE, LOCK, MOVE, COPY, etc..
It doesn’t sound like this would be that big a change for Groove if they’ve already got a CRUD interface, but the benefit is that you get all of HTTP’s other features and deployed support (e.g. Akamai) for free, plus any future extensions. RFC 2616 isn’t 420K in size for nothing, and you’re not going to ever be able to adequately replace it with a 5K WSDL file.
So this is quite encouraging, but let’s try to nip the “REST interface = any limited set of methods” misconception in the bud before it gets too wide spread.
Dave made the following suggestion for a SOAP definition;
It’s a simple way to call procedures running on other machines, on other OSes, written in other languages, using different economic systems, without being forced to pay a tax to Microsoft, IBM, Apple, Sun or the W3C.
SOAP isn’t that at all. That’s XML-RPC. Dave’s a bright guy who writes great software, but when it comes to distributed systems, there’s a lot he doesn’t understand.
The SOAP 1.2 spec defines SOAP as;
SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.
Which is a pretty decent definition, though not very detailed as to how one actually might use it. For a better definition, I look to SOAP’s brethren, PEP. It’s defined as;
The Protocol Extension Protocol (PEP) is an extension mechanism designed to accommodate dynamic extension of HTTP applications by software components; and to address the tension between private agreement and public specification.
Of course, SOAP isn’t tied to HTTP, but PEP didn’t really need to be either. It could also be patched to be an extension protocol for non-HTTP protocols, as SOAP 1.1 was “patched” in the form of SOAP 1.2.
Please, if SOAP has any chance of success, let’s try to distance it from RPC.
A couple of recent blogs and messages I’ve seen prompted me to write this. They both suggest that a “SOAP message” is necessarily a “message”. I disagree.
When bound to an application protocol, a SOAP message/envelope is not a message because it doesn’t contain the necessary information with which to understand what it means. For example, a SOAP envelope which included a HR-XML resume is not a message, because it doesn’t say what is to be done with the resume; is it to be forwarded on to somebody else? Submitted as part of a job application? Meant to update an existing resume? This is where the envelope of the underlying protocol, such as HTTP comes in; the HTTP request line (method, URI, version), headers, and the body which includes the SOAP envelope, forms the entire message.
If HTTP were a transport protocol, then a SOAP envelope/message sent over HTTP would always be a message. But it isn’t, it’s an application protocol. And please don’t think this is nitpicking. Far from it, I believe it’s the single biggest misunderstanding that has lead us to where we are at with Web services (i.e. a mess). If people knew what an application protocol was, I think many more (not all, of course) would have thought twice about proceeding with Web services.
Paul writes that innovation in the browser ain’t dead yet. I agree. From a distributed systems POV, I think there’s two important things that need to happen to the browser, in addition to the richer languages that Paul talks about (and don’t forget about RDF and OWL!);
- making the browser a peer
- allowing the browser to own application state
The former deals with integrating a Web server into the Web browser, enabling the “Two Way Web”, like KnowNow and Idokorro (my company) do.
The latter, related to the former, suggests that cookies can be replaced by purely client-side application state. What this would look like, is that you’d drag-and-drop items from a browser window into a desktop-located container – for example, a shopping basket – and then to check out, you drag the container back to the page. This keeps the session state – the basket – on the client, per REST’s Stateless constraint. This would require an extension to HTML/XHTML to support draggable objects, as well as a means to support file upload via a drop action (i.e. targetted at some element on the page).
A message I sent to www-ws-arch this past summer seems to be making the rounds again. I don’t think I ever mentioned it in my weblog, so here ya go. Looks like it was mentioned on xml-dev, so perhaps that’s why. Er, and I forgot that I mentioned it in my “Playing Checkers with a Chess Set” blog too. Duh.
BTW, 10 kudos to whomever finds the “flaw” in the argument I made in that message. It’s not a fatal flaw, of course, but it does hilight the late binding issue, which I didn’t introduce in it (for fear of losing the simplicity of the point I was trying to make).
Update; the flaw is that when you get to the get/GET part, the message no longer means “get stock quote”, it just means “get a representation of what’s identified by this URI”. You find out if it’s a stock quote after you invoke GET. That’s late binding.