three levels of abstraction
things seem to appear to me in threes. not sure why that is.
usually because i almost always assume at least three possible solutions for
any identified problem. an old habit.
the pledge
but there you are. i think in threes. and i've been thinking about this quite a bit lately. i've been inspired by several events in the last few weeks (three weeks maybe[grin]?). the most notable of these is last weekend's RESTFest 2011 event in Greenville, SC. we spent q good portion of the weekend hacking hypermedia using my ALPS Microblog experiment as a starting point. i learned several cool things. i think some other folks did, too.
the turn
one of the things that i got out of the weekend was a clarified understanding of the co-operative roles that play out in a hypermedia system when it is implemented over a distributed network. in our case, we were using the Web, HTTP, XHTML, and some specs for a microblog problem domain. the task was to build servers and clients that implement the spec and work both indepedently and in concert. IOW, loosely-coupled hypermedia clients and server, built independently, that achieve high interoperability.
believe me - it was cool!
along the way i discovered my experimental spec was lacking in some important ways. i won't go into the details here except to say that, in the end, i'd made the mistake of conflating app-level semantics w/ message-level semantics. the result of this kind of (common) mistake is often reduced interoperability. lucky for me, i had several very smart folks helping me find these problems and minimize their impact.
so smart, BTW, that i'm pretty sure some of them will end up w/ their names on the revised ALPS spec soon.
the prestige
see, my problem was mixing levels of abstraction in my implementation of the spec. but i get a bit ahead. first, the three levels of abstraction that have occupied my mind of late:
- protocol (HTTP, FTP, etc.)
- message (HTML, Atom, etc.)
- domain (microblogging, accounting, etc.)
i've spent the last year or so focusing on identifying the relationship between the protocol abstraction and the message abstraction. i've done this by analyzing various existing media types; developing a set of H-Factors common to all message formats that want to express protocol-level features via hypermedia controls.
the next logical step is to analyze existing hypermedia implementations to locate and identify the general principles for expressing domain information within a hypermedia message. that's what the ALPS experiment is about. my problem was i mixed message semantics (layout and relationship of markup elements) with domain semantics (what data is required and how it should appear). it took just a couple client implementations right there on site to point out my short-comings. and i was most grateful.
because that's how i learned about my errors in abstraction for this particular set of circumstances.
i have a pretty good feel for the protocol-message interactions. IOW, i feel confident that i can suffciently express any protocol details within a message design (i.e. a MIME Media Type). now it's time to ramp up my thinking on the message-domain interactions. once that happens, i'll be looking to express the domain in a way that works for any message format. and that will pave the way for a clear abstraction of protocol, message, and domain. and that will lead, i think, to much better analysis and tooling; eventually to better developer experience during implementation, too.
believe me - it will be cool!