Web Things, by Mark Baker

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.

Patrick Logan writes, in response to another high profile “Web wins, Web wins!” post, this one by Mitch Kapor;

[…] how long before a web *server* is as common place on the laptop as the web browser is today?

Not as long as you might think, especially with wonderful hacks like a Javascript Web server(!!)

You can also do it the easy way, like I did for the company I founded in 2001; a combination J2ME Web browser and Web server for the RIM Blackberry. Man, the fun we had with that … RSS POSTs to Web pages with the update reflected in the bookmark list, remote editing of calendars and notepad entries… The sky was – and still is – the limit. Avoid the distractions; the Web is where the action’s at.

A couple of interesting snippets from Graham Glass. The first was a New Year’s resolution, “Evangelize the Semantic Web”. The second was a prediction;

The Semantic Web replaces Web Services as the most talked-about topic in the world of software, with emphasis on RDF and metadata.

I don’t expect the prediction to be realized – at least not this year – but it’s good to see this coming from the CTO of a Web services player. Presumably Webmethods has got something SemWeb-centric cooking. Good for them. I just hope it’s not based on the "-S" stuff which (largely) presumes a Web services architecture rather than the Web itself.