mca blog

i'll admit it: i have 'boundary issues.' lately i've been thinking about how hypermedia works between clients and servers and i'm seeing things in a different light. i see boundaries. now, sometimes seeing bright lines between things can be a problem; the lines can hinder understanding of the similiarities between things. but right now, i am working to clarify the boundaries in order to generate a new understanding (at least on my part) of how hypermedia works and how it can be leveraged in distributed network applications.

NOTE: as i have mentioned in recent posts, i am spending time this year experimentating with hypermedia. what follows is a brain dump of my ideas on the value of boundaries in hypermedia messages. this may not be very coherent and there are still holes in the idea, but it does accurately represent the current state of my thinking on the matter.

first, a small digression...

Fielding's three architectural elements

one of the things i find interesting about Fielding's 2001 dissertation is his observation about the elements of distributed network architecture. in chapter one, he states that there are three elements that deserve attention:

(start Fielding quote)

Components

A component is an abstract unit of software instructions and internal state that provides a transformation of data via its interface.

Connectors

A connector is an abstract mechanism that mediates communication, coordination, or cooperation among components.

Data

A datum is an element of information that is transferred from a component, or received by a component, via a connector.

(end Fielding quote)

The thing that strikes me here is that Fielding has expanded the traditional Component-Connector model by elevating Data to the architectural level. this was an important addition at the time. also, as i read it the first time, it showed me that - by rethinking a well-known conceptual model - new relationships, depdendencies, and interactions can be clearly observed.

end digression.

my three hypermedia elements

while my own thinking is not to be treated on the same level as Fielding's PhD work, i, too, have been re-thinking my conceptual model of hypermedia in order to discover new elements and aspects. the current evidence of this attempt is my idea that hypermedia messages carry multiple levels of information. not just the data, not just the application controls, but other information, too.

as a result of my efforts to refresh my concept of hypermedia and it's role in distributed network applications, i've come to view the messages passed between client and server as containing several distinct sets of information. these are:

Protocol information

Protocol information expresses the transfer protocol details understood by all participants in the network. these are usually application controls in the message that are mapped (via the media type documentation) to transfer protocol details (HTML.A tags map to HTTP.GET, etc.).

Domain information

Domain information expresses the specific semantics understood by the target participants (usually the origin server and the client). these are usually expressed using the @rel attribute in HTML, Atom, etc. (e.g. rel="customer", rel="edit", rel="search", etc.).

State information

State information expresses the transient state values for the particular request/response instance. these are usually expressed using pre-defined data elements within the media type (i.e. HTML.INPUT) but may also be expressed in rendering elements (i.e. HTML.LI, HTML.DT, etc.). state information may even be expressed using Cookies or other message meta-data.

i'll admit that last item (State) is particulary vague right now. today, i'm operating on the idea that it is possible to identify, understand, and manipulate State within a hypermedia message when the media type is sufficiently defined to do so. i'm testing some ways to do this, but more at another time...

improving evolvability

why am i talking about this right now? because i think, by applying this boundary model to hypermedia messages, it is possible to improve the capabilities and flexibilty of Web clients|agents|applications.

my contention is, in order to improve evolvability on the Web, hypermedia types must first be sufficiently designed to allow for clearly-defined, variable protocol understanding. for example, the HTML.A tag does not require the href attribute use the "http" scheme. second, the hypermedia type must be designed in such a way as to keep domain-specific information clearly separated from the protocol details. again HTML comes very close to this as it has a limited set of @rel values defined and most of them are very generic.

in my mind, the key is to define and adopt a well-understood way to communicate domain-specific information. the XMDP project is one such example. WSDL and WADL are similar attempts. i suspect a registered media type that pulls from these existing examples will do the trick.

finally, the hypermedia type needs to be designed in such a way as to allow clients to easily locate and manipulate state information within a message. this is handled well in the application/x-www-form-urlencoded media type definition, but not taken into account in most other media types. this lack of clear state semantics within messages is, i suspect, one of the main reasons most automated agents on the web are limited to read-only activities.

just how to go about describing this abstract "state information" is not yet clear to me. but i have already begun to map out some of the details in a way that seems promising. essentially, by defining a set of elements that the clients and servers will be expected to share, a "state profile" can emerge. this profile could be defined in a way that is understood by all parties. the details of how to manage and manipulate this stat can be left to each participant as a private implementation detail.

the missing link

so where is this leading? i contend that, with a clear set of Protocol, Domain and State boundaries, automated agents can be more powerful and flexible. in fact, with these three elements of hypermedia clarified and clearly deliniated in a message, a fourth element - a missing link - can be brought into the picture: a hypermedia DSL.

Hypermedia DSL

a Hypermedia DSL is domain-specific language designed to recognize the State elements within a message; understand the available Domain information, and be able to identify and execute the Protocol details provided.

IOW, when a hypermedia type has well-defined Procotol, Domain, and State information, it is possible to use a very simple turing-complete DSL to 'drive' an automated agent. the DSL might look something like this:

  while(!done)
  {
    if(exsits(state.item='boots')
    {
      done=true;
    }
    if(exists(link.item='boots')
    {
      store(state.item)
    }
    if(exists(link.search))
    { 
      actviate(link.search('boots'))
    }
  }

even though the above example is mere speculation, i will point out that the Restfulie framework already has a very compelling "Web DSL." (much more capable then the weak example i offere here). i suspect it is only a matter of time before this kind of work spreads and becomes more ubiquitous.

am i correct?

in the past, i would make public assertions and expect them to be correct. not so much anymore now, i am happy to expose my speculations and see where it leads. no matter the results, i'll have learned something in the process.

so i plod along. working through my 'boundary issues.' poking at the edges. attempting to make some headway in my experiments.

of course, once i have successfully delineated the boundaries, the most likely thing i'll do next is...

go beyond the boundaries