« Recovery.gov Overhaul | Main | Atom Landscape Update »

Saturday, June 06, 2009


Feed You can follow this conversation by subscribing to the comment feed for this post.

Stefan Tilkov

I see why you introduce this extra level of indirection, but I wonder whether it would not be easier to define a standardized link element syntax that can be used everywhere, and then map other vocabularies onto this as needed.


@stilkov, thanks for the comment. there are three main reasons why i think a discovery/description mechanism might be a better way to go than some reusable schema module:

- for media type designers: it's hard to predict what designers want to do. , for example, has three links (@src, @usemap, and @longdesc), and designing a schema module that would allow this kind of thing is possible (for example using XSD types), but might make things more complicated than intended.

- for media type publishers: links are one of the major constraints of REST, and such a language would provide a declarative and easy-to-use way of how to document that facet of a RESTful scenario.

- for media type users: decoupling the media type and the way how to discover links in it allows users to have different "perspectives" of a media types. for example, for the above example, you can ignore @longdesc if you're not interested. another example: you can augment the basic LDX (i have to think more about how that should work exactly, so that you could combine more than one LDX for discovering links in a document): extending HTML's basic LDX, you could select html:link[@rel='DCTERMS.creator']/@href and assign it the role "DC.creator" (ignoring the fact that there can be more than one role in @rel). the main point: by having a separate format, discovering links becomes a separate process that can be extended or changed by media type consumers.

i hope this answers your question. i am still working on some of the specifics (such as how to extend/combine LDX descriptions), but in general, LDX being separate from a media type's schema should be considered a feature and not a bug; at least that is where i started from (items 1 and 2 of my tiny "requirements list").

Felix Sasaki

Hello Erik,
maybe this (ITS 1.0)
provides some answers on how to create what you call inline, and how to relate it to out-of-line. The application area is totally different than yours, but the problems to solve are similar, e.g.: what is the precedence between inline (in the ITS terminology called "local" and out-of-line (in the ITS terminology called "global"), or can there be several out of lines and what happens in case of conflicts (e.g. a node is selected by XPath expressions with conflicting link information) etc.



thanks a lot for the pointer, @felix! this indeed looks like a very useful document to look at. i guess the problems are, at a certain level of abstraction, the same:

- how to have both inline and out-of-line notations for the same information.

- how to make both notations match the intended data model (in my case, link discovery and associating roles with them) without any restrictions.

- how to have well-defined rules on what's happening for all possible combinations of the available notations.

you pointed to the problem of combining inline and out-of-line information, and that's important. than there also can be more then one out-of-line information (for example one created by the media type creator, and another one created by a consumer). or there can be extensions of out-of-line information (a consumer extending the information created by the media type creator). finding some examples where some of these problems already have been tackled (such as in the ITS) definitely will help to come up with good solutions.

Felix Sasaki

Hi Erik again,
I agree, on a certain level of abstraction these are similiar problems. An additional pointer for the generalization of such problems is a paper I presented at Extreme Markup Languages 2006, see
esp sec. 5, fig 7.

Michael Hausenblas

Very useful stuff, indeed. Can you please clarify if or how this relates to LRDD [1] - maybe it can be aligned or integrated there?

I'd not go for the W3C path in this case, an IETF RFC is more promising in this area, IMHO. Let me know, happy to support you there ;)


[1] http://tools.ietf.org/html/draft-hammer-discovery-03


@michael, thanks for the comment and the LRDD pointer, i did not know of that draft so far. so my first impression of it is probably a bit superficial. i am not quite sure what LRDD is trying to achieve. it uses POWDER's "describedby" relation type (which would be a "role" in my terminology). it talks about , but probably means (lowercase) and even then it's not quite sure how such a link would be identified across media types. just by the local name matching "link" (case-insensitively)? or would it have to be in a special namespace (in which case XHTML and Atom do not qualify). there is no magic to element names, and this is exactly why i am proposing to have XPath selectors: they work on the Infoset (or XDM, based on which XPath version it will be), and thus allow you to work cleanly with XML's naming concept. as i said, my impression definitely is based on a first pass of LRDD, but it seems to me that LRDD simply enumerates a number of possibilities how in a dualistic web of resources/descriptions, implementations might find the description, given a resource URI and HTTP interactions. there seems to be a lot of dependencies on fluid specs (and the draft seems to define its own URI template method). my impression is that the draft mainly registers POWDER's describedby relation type, and a new field for the host-meta registry, and both of these registries currently do not exist. am i missing something?

so, to compare LRDD and LDX (based on my limited understanding of LRDD): LRDD seems to be concerned with how to find a resource description given a resource URI, and describes a number of ways how to do this description discovery. it also defines special registered values for two of the methods described. LDX only talks about how to identify links in XML-based media types, and is only concerned with discovering links (any links relevant for RESTful services, which probably are many more than just those linking to descriptions) and associating roles with them. LRDD's "describedby" relation type could be one such role, so theoretically speaking, LDX could be listed as one additional way of finding a resource's description in LRDD's list of methods, but only if the resource is XML-based and there is an LDX description for it.

Michael Hausenblas


Thanks for your answer, I think I see a bit clearer now.

So, yes, LRDD basically proposes three methods for discovery, namely HTTP Link: header, a well-known location and the element (XHTML, Atom), and assigns a sort of uniform interface/semantics to them. As it seems, no single method covers the broad range of use cases, this looks sensible to me. Please have also a look at [1], where Eran puts LRDD into context.

As I said, I dunno if it makes sense to align or integrate LDX and LRDD. We all operate on moving targets, right? ;)

Another thing that came to mind when I read your statement 'any links relevant for RESTful services, which probably are many more than just those linking to descriptions' - how about WADL? Frankly, as you know, I'm no REST expert, however wondering how LDX and WADL are related, or overlapping, respectively.


[1] http://www.hueniverse.com/hueniverse/2009/03/the-discovery-protocol-stack.html


@michael, you're bringing up all the right pointers! so, what about WADL and LDX? WADL focuses on what it calls "grammars" (the schemas for representations) and "resources" (which are a combination of HTTP methods and URI templates). as far as i know, WADL has no provisions to identify links with representations, it depends on the URI templates given in the WADL description (and i think this URI template focus is one of the main criticisms of WADL from a RESTful perspective). so in a way, LDX could augment WADL by adding link discovery to WADL's "grammar" concept. on the other hand, this would conflict a bit with WADL's approach of using URI templates for describing resource links, so i think there is some conceptual difference between LDX and WADL in terms of how they assume that links are being discovered. WADL is statically depending on WADL descriptions, LDX should be more dynamic/adaptive by being bound to media types, at least that's the idea.

The comments to this entry are closed.