I'll guess that Mark is referring to the argument that some make (especially Paul Prescod in http://webservices.xml.com/pub/a/ws/2002/04/24/google.html ) to the effect that the big problem with the SOAP interfaces such as the one to Google is that one can't hyperlink to / bookmark a Google SOAP invocation the way one can using Google's URI syntax. I'm pretty sure that this was the "a-HA" moment in the W3C SOAP community, when people began to grok why Prescod and Baker were asking "where is the Web in Web Services?". This led to the (partial) reconciliation of SOAP and REST that Jon Udell describes in
http://www.infoworld.com/article/02/05/17/020520pllinks_1.html
Mark takes this further, IIRC, to argue that the SOAP GET binding doesn't go far enough and that the notion of "distributed hypermedia" should be put at the center of Web services. I'm not exactly sure how (or if) this is supposed to replace the "reliable, secure, transacted, orchestrated" Web services protocol stack that IBM and MS promote http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsOverView.asp ... it would be very interesting to hear his take on this 18 months after the SOAP/REST reconciliation at W3C.
Jon talks about addressability, and the absurd case where the HTML-based help pages for a complex GUI simply describe the series of steps required. They can't take the next logical step (provide links to execute those actions), because the elements of the GUI are not addressable.
Now, I can create a link that points to the Google search results for "Dare Obasanjo" in HTML:
http://www.google.com/search?q=Dare+Obasanjo
This sort of thing has proven to be very useful when writing. Both I and Sam (and perhaps you as well) have used such constructs in the course of writing our weblogs to refer to the results of a particular Google search.
I would also like to do this with the Google API. Not only in the course of technical writing, but also in the course of programming other services that sit on top of it. But I can't, because calls to that API are not addressable.
This doesn't necessarily mean they have to switch to a pure-HTTP-GET interface (although they had something exactly like that a few years ago, you could replace "search" with "xml" in the URI of any Google search and get results in XML instead of HTML). Files on FTP servers are addressable. IRC channels are addressable. Jabber identities are addressable. EDonkey downloads are addressable. None of these use HTTP. But the Google API manages to use HTTP -- the most widely-addressed transport in history -- and not be addressable.
Lest you think I'm pulling an Orlowski and simply picking on Google because they're Google, Microsoft.com's web services do the same thing. Amazon's web services, on the other hand, offer 2 interfaces, one based on SOAP and one based on XML-over-HTTP-GET. The latter (addressable) alternative may seem primitive (because we've all been brainwashed into thinking that SOAP is "more advanced" than XML-over-HTTP), but the fact that the latter is addressable has enabled a whole range of 3rd-party innovation. Case in point: Amazon Light ( http://www.kokogiak.com/amazon2/ ), which has built an entire new frontend to Amazon with an XSLT stylesheet.
Let's all keep this in mind when we're debating what we want out of an API. You may think you want "simple" RPC-style function calls, but you'll foster more true innovation with addressability.
Mike and Mark,
I see what you mean. This is one of the reasons I'm glad that the "Service Oriented Architecture" buzzphrase is beginning to eclipse "XML Web Services". It tends to eliminate the confusion that the folks who are trying to design the next generation of CORBA/DCOM/RMI should care about things like the ability to link to the results of a service invokation from a web page.
I completely agree that for Web Services addressability and linking are key especially if they want to participate in the rest of the Web infrastructure. This is one of the reasons I became interested in RESTful approaches to building applications that exchange XML across the Web.
However based on the few discussions I've seen amongst the XML Web Services/Service Oriented Architecture crowd, I suspect that a large population of them aren't really interested in building services for the Web just reusing Web technologies. Of course, this is XML all over again.
PS: Mike I barely see you writing anymore. No blogs and no XML-DEV. Is everything OK?
Is it me or is anyone else bothered by examples like this ASP.NET DataGrid? How would you send someone a link to anything but the first page?
Otherwise, wouldn't the closest thing to what Jon is asking for be Mozilla's much overlooked XUL?
+1 to all this.
So much /Web \S+/ stuff seems to forget the joys of hyperlinking and so on and just use http as a transport and/or XML as a standalone format. Nothing wrong with that per se, it's just missing out on the potential and encouraging blind alleys.
It's rather like getting in a taxi and saying "take me to a hotel". But the taxi windows are blacked out, and so you can't see you're driving past dozens of perfectly respectable hotels to get to the taxi-driver's brother-in-law's seedy motel across town. Or something.
btw, I really liked the Flash fisheye menu Jon pointed to in the article, so had a crack at the same thing in CSS+Javascript:
http://dannyayers.com/2003/10/fisheye.html
(notes: http://dannyayers.com/archives/001971.html)
Mark:
With Regard to... "They can't take the next logical step (provide links to execute those actions), because the elements of the GUI are not addressable."
The elements of the GUI are not addressable for a reason. The technical limitations are easily surmountable by any of the bright people in Redmond. What's not easily soluble is the fact that when executable code becomes addressable by the browser, the security holes that they already have get worse by an order of magnitude. This is a classic case of balancing between design constraints: 1) wouldn't it be lovely if everything was addressable and automatable 2) yeah, but script kiddies would be thrilled too!
The exact GUI context in Jon's article was not clear to me, but it seems that the approach taken in modern versions of winhelp, where various control panel applets can be launched directly from the help system, would suffice. Obviously, implementing that in win32 is quite a bit different than HTML. I guess what I'm trying to say is that if the parent app is a win32 app hosting the browser component then implementing the "link" class is straightforward. Not so if the browser is doing the driving. I thought I remembered seeing this in some MMC context once, but it's been forever and a day since I've looked at MMC.
Danny:
Nice work! Reminds me of ben bederson's work on zoomable UI at U. Maryland:
http://www.cs.umd.edu/hcil/jazz/
Fortunately, that one's addressable!