type|use semantics
Warning: unsubstantiated musings ahead. i'd turn back if i were you.
as i spend more time exploring the implications of designing
Hypermedia Types, and talking with
others about this topic, i am starting the think that my work to abstract the bits of a media type
that make up essential hypermedia aspects
is falling short.
i think i may have missed an important abstraction layer: the implementation itself.
Robinson, Webber, and Parastatidis spend considerable time talking about Domain Application Protocols (90 minute video) in their excellent book: REST in Practice and i think they're onto something very important. there are some implementation-level protocol understandings that must be acknowledged and dealt with when building distributed network applications. i think Mike Kelly summed it up nicely in a recent post to the #REST irc channel:
"...media types are [for the] uniform interface, link relations are for specific applications."
if i understand Mike Kelly's point, a media type defintion may be able to describe the hypermedia interactions needed in order to make that media type useful in a general way, but that same media type may not be able to describe all the possible implementation-specific interactions for a single "application domain." Kelly's suggestion seems to be that the @rel attribute should be used to communicate application-specific information to clients (and their human users).
currently, HTML uses rel="stylesheet" to tell web browsers to start processing the content at the other end of the URI as a CSS or possibly XSLT media type. AtomPub uses @rel="edit" to tell clients the associated link should be used to edit the referenced resource. in both these cases, the specific link relation value is a fundamental aspect of the media type design, not an application-specific one.
and this may be a flaw.
if, to follow Mike Kelly's lead, the link relations are reserved for describing implementation specifics, it might be easier to build clients that understand (and can differentiate between) media type semantics and application semantics. this can lead to building clients that have the ability to dynamically identify, download, and understand a wide range of what Robinson, et al call "application domain protocol."
another fellow #REST channel denizen (Darrel Miller) pointed out HTML5's custom scheme and content handlers spec. although this ability to register and resolve unknown content types falls short of what i'm describing in this post, if this HTML5 feature survives through the final cut, it might lead to some interesting advancements in the future. there may be a day sometime in the future when generic Web clients (like the common Web browser) will have the ability to discover, download, and "learn" new implementation-specific read/write semantics without requiring rewriting the code, re-deploying the app, or downloading a complete binary "plug-in." we may someday see a kind of "CSS stylesheet" for domain application protocols.
and that would be a great thing.