mca blog

i must confess; i am old enough to remember the "generic brand" movement in US grocery stores in the 1980s. the basic idea was "generic was good enough;" that you didn't need to pay the cost of the need-less brand-awareness advertising that didn't add to the value of the product itself. for example: "bleach is bleach - why pay for Brand X bleach when you can get 'generic' bleach at 1/2 the price?" this seemed like a reasonable question at the time. of course, this generic brand idea was soon applied to foodstuffs where there most likely was a noticeable difference. for example, can you imagine what 'generic' beer tasted like? in case you're curious, it was terrible.

and this applies how?

over the last several months i've continued to experiment w/ designing and implementing custom media types. this work has been met w/ a wide range of reactions; most of which are captured in this recent thread on the rest-discuss email list. as is the case in the afrementioned thread, generally the talk gets around to the value of "specific" (not custom) vs. "generic" media types. in particular, what effects media type has on coding clients and servers and, in some more esoteric discussions, what effects custom media types have on the viablility of a RESTful Web (fill in your own definitions for all those multi-ordinal terms[grin]).

the continuum

my explorations of media type design have run from 'generic' (JSON-H [example]) to the specific (Maze+XML - [registration pending]). i've designed some that are based on XHTML and take advantage of that media type's built-in hypermedia controls. and i've designed some that are based on plain XML and require defining the hypermedia controls as part of the media type documentation. i have a number of media types in various stages of design and implementation (mostly in private distributed networks).

custom != specific

my point here is to highlight my wide range of approaches at media type design (so far). while it's true i tout the potential positive values of custom media types, it is not at all true that i favor 'generic' over 'specific' designs. it's important keep these two aspects ('custom' vs. 'generic|specific') of a media type clearly separated. the assumption that goes along with the 'custom' attribute is that the media type suffers from a small reach or limited distribution. also, there are folks who are of the opinion that media types whose reach is limited should not be considered 'valid' or 'viable' media types (for "the Web" or for "the RESTful Web",etc.).

but i digress...

getting to the point

the main point of this post is to talk about generic and specific properties of a media type. IOW, what qualifies a media type as 'generic'? usually folks have in mind HTML when they think of a generic type; why is that? and what do people have in mind when they think of a 'specific' media type? PNG? CSS? Atom?

i think the ability to clearly and cleanly differentiate between 'generic' and 'specific' is important to making progress in understanding the real nature and use of media types on the Web. i also think this progress is needed in order to make advances in M2M (machine-to-machine) programming on the Web. in my current work, knowing how to identify each, how to speak clearly about the merits and drawbacks of each, and ways to incorporate these aspects into your own designs and implementations is paramount.

one method i will use to try to clarify talk on this subject is to introduce a way to stop labeling media types as 'generic' or 'specific.' instead, i will use treat these words as qualities of a media type (e.g. the 'generic' quality of a given media type, the 'specific' quality, etc.). you'll also note that i wrap these words in single-quotes. this is my way of indicating the vague nature of these terms. we all have our own interpretations - our own meanings - for these words. hopefully, my assertions below will help readers understand my meaning for these words as they are used in this blog post.

a hypermedia type is...

in an effort to promote understanding and clean up some muddled thinking regarding 'generic', 'specific', and 'custom' as these words apply to media types on the Web, i'll make some assertions. let me start by saying i will only cover 'hypermedia' types in this narrative: ones that support using hypermedia as a way to transfer state between client and server.

so...

A Hypermedia type is a media type that expresses one or more of the H Factors via native application controls.

while some might quibble w/ the membership of my H Factor collection, i think it's sufficient for the current discussion.

what is 'generic' in a media type?

so what aspects of a media type can be characterized as 'generic'? i claim:

The 'generic' aspects of a media type are expressed as hypermedia controls designed to support protocol-level semantics.

IOW, the media type provides hypermedia controls that support some portion of the target transfer-level protocol(s). in HTTP this would be the URIs, methods, status codes, request|response bodies, headers, etc. HTML is a media type that exhibits this quality.

what is 'specific' in a media type?

well, then what aspects of media type can be characterized as 'specific'? i claim that:

The 'specific' aspects media type are expressed hypermedia controls designed to support not only protocol-level semantics, but also application-level semantics.

IOW, the hypermedia controls in the media type go beyond supporting transfer-level protocols. this semantic 'specificity' may be expressed using link relation values and/or application-specific elements within the entity body.

Atom is a media type that exhibits this quality. RFC4287 identifies five application-level semantics in the form of link relation values (self, alternate, related, enclosure, & via). RFC5023 adds two more (edit and edit-media).

some might argue that Atom does not qualify as a specific media type since it's link relation values are 'relatively' generic (i.e. self, etc.). however, i think this is really a matter of degree. while shopping-cart is more specific than collection and customer is more specific than item, in all cases, the semantic information goes beyond transfer-level protocols.

semantics, levels, and degrees

i've written along this line before; that the presence of link relation values, their definition, and use at runtime is a pretty good sign of application-level semantics beyond the transfer-protocol. HTML uses rel="stylesheet" (and others) to change the way the User Agent (the browser) treats the information; this is beyond transfer-level protocols.

so, from my POV, the nature of the 'generic' and 'specific' discussion is not binary, but a multi-valued argument. it's a false choice; a non-existent dichotomy. and it's not the 'right' discussion to have when contempling media type design. the issue is not whether we should design|use 'generic' or 'specific' media types. the issue is how 'generic|specific' is 'overly-generic|specific.' or, if you prefer, how 'specific|generic' is 'specific|generic enough?'

in truth, those of us who work with hypermedia types deal with this contiuum every day. some of us do it so often - so habituatlly - that we have forgotten that this continuum even exists. like it or not, we all deal with some level of 'specificity' in our hypermedia types. the difference is in how each of us recognize and approach with it. some of us embrace and extend this aspect of hypermedia. some of us ignore it and/or work to actively reduce it.

yeah, i'll keep experimenting, but...

in my current experiments, 'generic', 'specific', and 'custom' are not inherently 'bad' or 'good.' they are merely a few of the many qualities and aspects of a media type design. and i plan to explore, exploit, and learn from these (and other) qualities as much as i am able. and that means i'll be talking about them and exhibiting them in various forms into the near future (at least).

but there is one thing i will not be doing any time soon:

i will not be chugging any 'generic' beer.