mca blog

today i posted the first working draft of a new hypermedia design i am (humbly) calling "Uber Hypermedia." i've been sitting on a handful of media type designs for a couple years and finally have decided to turn my scraps of notes into something tangible. this gives me a chance to work out my ideas, get feedback from others, and -- in a small way -- contribute to the improvement of media type design in general.

design goals

here is some text from the introductory copy of this current draft spec:

The Uber message format is a minimal read/write hypermedia type designed to support simple state transfers and ad-hoc hypermedia-based transitions. This document describes both the XML and JSON variants of the format and provides guidelines for supporting Uber messages over the HTTP protocol.

The Uber message model has a number of design goals:

• Keep the message structure as lean as possible.
• Support all the H-Factors in hypermedia controls.
• Be compatible with multiple protocols (e.g. HTTP, CoAP, etc.)
• Maintain fidelity for more than one base message format (XML, JSON, etc.)

"Less is More"

like Architect Ludwig Mies van der Rohe, i've adopted the "Less is More" approach. this media-type design has only three elements: uber (the doc root), data (a recursive element for data and transitions), and error (for when things go wrong).

my hope here is that keeping the model super simple will make is easier to implement parsers and validators as well as make it easier to convert internal object models into messages and back again.

De Stijl

and similar to Piet Mondrian and other members of the Dutch De Stijl movement, i wanted to focus on the minimalist, abstraction of what a hypermedia message is. to this end, i tried to reduce hypermedia down to the bare essentials of data and transition.

there is only one element (data) to express both content (e.g. "Mike Amundsen") as well as express all the possible hypermedia actions such as those contained in HTML's a, img iframe, input, and form elements.

repetition and recursion

i also find the reptition and recursive patterns in the minimal music of Steve Reich (and others) very appealing and have used that as an inspiration in creating a format where the real information is found in continuously-nested copies of the same (data) element, each with its own slight variation.

essentially, creating a service that supports the Uber Hypermedia format means embracing the recursion and repetition that altready exists in our computer models. hopefully, this approach will make it realtively easy to handle conversions from internal object trees into external Uber messages.

comment, clone, and pull

i've posted the working draft in github in hopes that those wishing to provide feedback can comment, add issues, clone and even submit pull requests to help me refine and improve the design. i have yet to build any client or server implementations yet (that's the next step) and would love to hear from those wishing to do the same.

so there it is; a hypermedia format with just three elements, eleven attributes, and only seven reserved strings. i'm a man of small ambitions for this project [grin]!