(Still throwing off random sparks ignited at the W3C Enterprise Workshop.)

Technology, like religion, eventually begins to accrete dogma.  In the case of the Web there seems to be a growing trend of thinking that if something has proven to be "good", alternatives to that thing must be alternatives to "good", and we all know the only alternative to "good" is "bad," right?  If Mohammed is the true prophet, Jesus can't be.  If REST is good, WS-* can't be.

A case in point:  The fact that a URI can be communicated in plain text and thus in a wide variety of contexts is viewed as a great strength of the web.  The fact that one can write a URI in an email message, in a print publication, or even on the side of a bus is often touted as a virtue of URI identifiers.  The ability to write a URI on the side of a bus is undoubtedly good.  An identifier that can't easily be transcribed onto a rolling billboard thus must be bad, right?  Paul's hilarious graphic of an EPR on the side of a bus is an example, with the implicit message that because URIs are good, EPRs must be bad.

Although Paul was partly making a different point, taking this incipient dogma too seriously is misguided.  Very few of the URLs pointing to interesting resources on the web are actually simple enough to write on the side of the bus and survive human transcription.  Paul unfairly compares an EPR of horrible complexity to a simple URL.  Only a small percentage of the URLs in use today are simple enough to be placed on that bus with a reasonable chance of success.  And even the simple ones rely on years of forced adaptation to make such finger- and tongue-twisters as "haytch-tee-tee-pee-colon-whack-whack" even nominally acceptable.  Just because human transcription is good for some identifiers, should one conclude that it must be a quality desirable for all identifiers?  Are long and complicated URIs "bad"?  I argue that they simply aren't appropriate for use in the context of human transcription.  EPRs are specifically designed for use in the context of Web services - i.e. machine-to-machine communication on the web.  I seriously doubt that machines are going to be reading sides of busses.  And if they do, verbosity is still unlikely to be one of the primary problems.  The goodness of a URI on the side of a bus doesn't imply the overall badness of EPRs.

In the context of machine-to-machine communication, often more structure is better.  A structured identifier can indicate the split between metadata and data.  It can have definite rules about where the identifier starts and ends - wouldn't it be nice if plain-text email readers could detect the start and end of multi-line URLs?  It can have a uniform syntax for describing the "parts" of the identifier - URIs embed a pretty complicated microsyntax.  It can have simpler, more uniform rules for encoding special characters.  It can put the information necessary to access a particular resource within the identifier instead of hiding it in cookies and session state as is common in HTTP resources.  I'm not claiming that EPRs are all good, just pointing out that within a given context perhaps they aren't all bad.

Another example of a bit of good advice turned into dogma and used to bludgeon the innocent was evident in Nick Gall's W3C Enterprise Workshop paper claiming:

Nowhere in the vast multitude of WS-* specifications or the articles or papers describing them is there any imperative or even any emphasis that a Web Service should return an XML document that is populated references to other Web resources, ie URIs.  But it is a fundamental principle of the Web that good Web resources don't "dead end" the Web; instead, they return representations filled with URIs that link to other Web resources.

First of all, I'm wary of even dignifying this so-called "principle" with that label.  For human interaction, for searching and cataloging based on simulating human navigation patterns, pages full of links are good.  Especially when the content of that page isn't terribly useful it's nice to be able to click virtually at random and escape into the soothing world of advertising pitches.  But for a particular user, the majority of links in a page never get used.  What is a machine going to do with a bunch of random links?  In machine-to-machine communication, links are undoubtedly going to be much fewer in quantity, but much higher in quality.  And if the service is doing something useful on behalf of a user that doesn't require the transmission of lots of links, is that therefore a bad service?  A service should return precisely the number of links necessary for it to do useful work.  No more, and no less.

The danger of dogma is that it takes something that is right and useful in context, and applies it to contexts where it often is neither right, nor useful.  Apply Cold War politics to the so-called War on Terror and you get Iraq.  Apply Jesus' celibacy to much less spiritual theocrats and you get sex abuse.  Apply something like the carefully constrained Web Architecture out of context and the consequences aren't nearly so disastrous - but you will look kind of silly.  Best to keep it to a minimum.  Ideally, no larger than will fit comfortably on the side of a bus.