Web Things, by Mark Baker

If it’s in a protocol stack, it’s a protocol.

I forgot to mention that I proposed an issue to the TAG, as the WS-Addressing WG refused to accept it.

This is an interesting one, since it’s not so much a test of URIs vs. EPRs (though that one will be entertaining!) as much as it is a test whether the TAG agrees that protocol independence – where a SOAP message’s semantics are independent of the underlying protocol – is counter to Web architecture.

I’ve been meaning to do this for years now, but after a recent reminder about how poorly understood state is, I decided to make some time.

It’s no where near complete, as you can tell, but I think there’s enough there to be useful to a lot of people. So I present to you, the State FAQ!

Of course, like any decent FAQ, it’s on a Wiki, so let’s work together to make it better. Cheers!

I’ll be hanging out in Sunnyvale Jan 21-23, with the morning of the Friday (21st), and the whole day Saturday, free.

Who wants to get together?

One thing’s for sure, I’ll be in the mood for a serious sushi outing. Ottawa’s got to be the worst place on Planet Earth for it; no sushi-only establishments, and of the better Japanese restaurants, they don’t do omakase, and the sushi’s only barely passable!

Update; I suppose I should update this to say that Totoya is the first decent Sushi place I’ve found in Ottawa. It’s a bit on the expensive side, but their fish is by far the best I’ve had in town, and rivals meals I’ve had in Tokyo and Vancouver. Sushi 88 is nice as well; good variety and quite affordable, but not quite as tasty as Totoya.

Another good article from Joe. I left a comment, but wanted to repost it here, since I think this is the most succinct description I’ve offered for explaining this critical point.

Nice job again Joe, but I think you’re a little (and I do mean *little* 8-) too rough on the existing service when you say “This is an RPC protocol trying to run over HTTP, and that misalignment is where the problems arise”. With the ListMyQueues and Read operations, putting them in a URI such that a GET returns the data *is* perfectly RESTful. This is because when in URI form, the effective operation – that which the client asks be done, and expects is done when receiving a successful response – is GET, not ListMyQueues.

It’s very(!) easy to misunderstand this point; the same point which is also, I believe, the principle impediment which prevents proponents of document oriented Web services from realizing that REST and the Web is what they’ve been trying to build.

After a two-plus year hiatus, I’m returning to active duty at the W3C. Justsystem, my principle client, has just joined as full members. I’m now a member of the Compound Document Formats WG, which shouldn’t come as any surprise given the problem space tackled by xfy, the technology we previewed in November.

Dave takes me to task for using XMethod‘s number of registered services as a metric in my attempt to track the growth of Web services on the Internet.

I know it’s not a great metric, sure, but I’m not extracting very much information from it. I’m certainly not claiming that there were, for example, only 376 of them in existence last month. All I’m saying by counting them is that wouldn’t you expect that if Web services were seeing success on the Internet, then the number at XMethods would also be increasing?

But my objective here isn’t sinister. I’m honestly just looking for a metric which reflects SOAP/SOA deployment on the Internet, in the spirit of trying to measure “success” in a meaningful way; not “hype” or “products supporting it”, but actual use in the context it was designed for. If anybody’s got a better one (which shouldn’t be hard at all), I’m all ears.

Stefan asks;

Is it really a protocol change if I change e.g. an RPC-style WS operation name? Doesn’t that very much depend on my point of view, i.e. whether I write (or at least look at) my code as dependent on the lower-level protocol (which is always going to be one level more generic that my high-level protocol) or dependent on the higher-level protocol?

Urgh, protocols. There’s so much confusion around the word that I think Stefan would be much better served to ask the question from a software architecture POV. I think the equivalent would be this;

Is the connector changed by a change in an operation name?

The answer to that is clearly, unequivocally, yes; connector semantics include application semantics, by definition.

No matter how you choose to design your connectors, be it with a single specification (ala Internet based apps like the Web), or be it with more than one (ala Web services, with domain-specific-semantics/WSDL/SOAP/binding), you can’t escape the fact that a change in operation means a change in connector means an impact to interoperability.

I’ll leave the mapping of this explanation to the use of the word “protocol” as an exercise for the reader. 8-)

I’ve been meaning to comment on these for a few weeks now, but it seems they’re making the rounds; hCard and hCalendar, HTML-encoded equivalents of the vCard and iCalendar specs. Check out this example hCard;

<span class="vcard">
 <a href="http://tantek.com/">
  <span class="n" style="display:none"> <!-- hide this from display with CSS -->
   <span class="Family-Name">Celik</span>
   <span class="Given-Name">Tantek</span>
  </span>

  <span class="fn">Tantek Celik</span>
 </a>
</span>

Isn’t that freaking gorgeous? Let’s think about what constraints Tantek had to work within in order to produce that…

• de-facto extensibility behaviour of common browsers
• inline styling when extensibility doesn’t give you what you need
• "span" as a semantic annotation mechanism

Beautiful! Web hackery at its best.

My only concern there is that without a URI to ground the class names (ala the same problem that XML namespaces were developed to address), you run the risk of confusing aggregators when names overlap. Perhaps the HTML profile element could be used, though associating the different profiles with specific class names would seem to require an HTML extension. Hmmm…

Anyhow, while I still believe that RDF will do the bulk of the heavy lifting for the Semantic Web in the long run, cool stuff like this and GRDDL will almost certainly help bootstrap it. Nice job.

Just stumbled upon a requirement to use REST for an EU software project;

   System to system interoperability

   Should use:

      1. Roy Fielding's REST principles

Of course, in the same list they also mention “XML-RPC”, which cannot be used RESTfully (unlike SOAP, also in the list), but it’s a start. I’ve talked with folks from other government projects, and they wanted to use REST because they wanted to use the principles that made the Web work; they just weren’t exactly sure how to go about it.