Unobtrusive link info

Mr Amundsen’s recent post regarding the design of “semantic machine media types” got me thinking about media type design. One of the commonly encouraged practices, particularly on the REST discuss group, is the use of link elements.

I really dislike this idea. It sets my teeth on edge because it treats links – which are possibly the most important bits of data in existence – as second class citizens. It is easiest to show what i mean with a bit of extrapolation:

<complexElement rel="entry">
  <string rel="id">234132</string>
  <string rel="displayName">Peter Williams</string>
  <complexElement rel="name">
    <string rel="familyName">Williams</string>
    <string rel="givenName">Peter</string>
  </complexElement>
  <complexElement rel="emails">
    <link rel="email" href="mailto:pezra@barleyenough.org"/>
    <string rel="type">personal</string>
  </complexElement>
</complexElement>

That is what a portable contact might look like if we treated all data the way link elements work. That example looks pretty ugly to me, as i suspect it does to most people. It is ugly because very important information regarding the role of elements is relegated to a subsidiarity position in favor of fairly unimportant information about its type. However, link elements do to links exactly what my example does to all the data. The effect is that properties whose values happen to be independently addressable resources are obfuscated.

The revealed preference of the world is against link elements. Just look at pretty much any format that embeds application specific semantics. As far as i know, there is not a single widely used format that actually represents its links as link elements. Even atom uses properly named elements for most its links. The link element it defines is largely relegated to the back water of extensibility.

One benefit that link elements have, or at least could have if they where more widely used, is the facilitation of standard link processing tools. Fortunately, we do not have to give up the expressiveness and clarity of intention revealing names to achieve this result. Rather than obscuring the links we could just treat them as normal data. The additional information needed to support standard tools could be added in a relatively unobtrusive way. Consider the following:

<entry xmlns:link="http://unobtrusive-generic-linking.org/">
  ...
  <emails>
    <value link:hrefDisposition="elementContent" 
           link:rel="foo">
      mailto:pezra@barelyenough.org</value>
    <type>personal</type>
  <emails>
</entry>

This is idea is similar to xLink but more flexible and simpler to use.

You could expand the idea to JSON with relative ease. Consider the following expansion of the portable contacts json format tagged with some unobtrusive link info.

{"entry": [
  {"id": "42",
  "emails":
    [{"address"   : "mailto:pezra@barelyenough.org",
      "type"      : "personal",
      "_linkInfo" : {"hrefDisposition" : "address", 
                     "rel" : "foo"}}]}]}

Unobtrusive link info makes links visible to and usable by generic link processing tools while protecting the use of intention revealing names that format designers, and users, want. This is important because it allows new formats to reuse “standard” link semantics more easily and uniformly.

11 comments on “Unobtrusive link info

  1. -

    I’m surprised at your comment on Atom’s use of links. Atom and AtomPub use links for hypertext. Extensibilty is inherent in hypertext.

    • - Post author

      My point was that the link element is not even used uniformly in Atom. Many of the links defined by Atom are implemented with constructs other than the link element. I don’t think this is bad. It is just an indication that the link element construct is quite awkward in many situations.

      I think we improve the situation by creating a less awkward approach to self describing links.

  2. -

    I think elements named LINK are “first order” members of the type. I think elements named “Email” w/ an attribute named “link” are less direct expressions of links.

    What am I missing?

    BTW – I was actually re-reading the XLink spec this past weekend!

  3. - Post author

    As a user of the data the linkyness of a property is far less important than the semantics of the property. The fact that i have a persons primary email address is important. Having a link w/o knowing what it means is of no value.

    I don’t love the idea of a link attribute but it does provide a useful benefit. Given the IANA link relation registry, if a standard way of tagging arbitrary XML nodes at containing URIs of a particular relation it would allow clients to extract some value even from formats that they do not completely understand. I see it as a more practical way to get the perceived benefits of the link element.

    The link element trades clarity of encoding and simplicity in native client for visibility of links to generic link rel clients. I just don’t think we have to give up all the clarity and simplicity to gain that visibility.

  4. -

    Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the “rel” attribte it is self describing, but just take a look at Peter’s example of a self describing document. I looks more like a xsd than a xml !
    May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don’t know where it takes you, the semantic ?
    May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.

    Peter, may be i’m wrong but isn’t less cumbersome


    Than

    mailto:pezra@barelyenough.org
    personal

    Aren’t you keeping some “meta-meta data” in the document ? shouldn’t the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?

  5. -

    Like integer or plain string, i think link should be treated as a data type. Link as an element is just too vague. Of course with the “rel” attribte it is self describing, but just take a look at Peter’s example of a self describing document. I looks more like a xsd than a xml !
    May be the use of Link element is encouraged since it is thought to be a fundamental peace of data in the web and should be easily recognizable, hence an element named Link. But what is a link worth if you don’t know where it takes you, the semantic ?
    May be there might be use cases for parsing links without caring (or caring less) about the linked resource, well, for that, it is not really hard for a parser to know if an element value is a link or not.

    Peter, may be i’m wrong but isn’t less cumbersome


    Than

    mailto:pezra@barelyenough.org
    personal

    Aren’t you keeping some “meta-meta data” in the document ? shouldn’t the consumer just know that email tag ? or is the purpose to maintain the generic aspect of the link ?

  6. -

    Sorry i had some problems with formatting

  7. - Post author

    Reda B.,

    There are advantages of using a standard link mechanism, such as a atom:link element or a xlink attribute. Using standardized linking structures allow clients that do not understand the semantics of your doctype to extract some link related information. Such standardization should allow libraries to be built that are less media type specific, and therefore more reusable.

    That being said i think that the Link header field is a better way to deal with the sorts of links that benefit from standardization.

Comments are closed.