The new discovery framework, commonly referred to as XRD, has been designed with strong support for modularity and re-usability. This of course, adds complexity as each component of the protocol stack has its own specification (and standardization venue). At this point, all the components except for XRD have a draft specification available. The good news is, that the XRD spec will directly incorporate everything you need to know about the other layers to use it.
The web is made out of links. But unlike what most people think, links are more than just markup in hypertext. They are one of the most fundamental web architecture building blocks, and we are just starting to fully appreciate their usefulness. In my previous post on redefining discovery, I explained why the current discovery framework described by XRDS and used by OpenID is problematic.
The new XRD protocol stack includes three layer, each useful on its own:
Discovery tries to answer two questions:
- Given a resource (identified by a URI), where can I find information about it?
- What format is this ‘information about’ in? How do I make sense of it and use it?
Looking at the protocol stack, the bottom two layers (Links and LRDD) answer the first question (where) and the top layer (XRD) answers the second question (how). Let’s take a look at each layer and what it provides:
- XRD - the Extensible Resource Descriptor is a simple XML-based schema for describing resources. The schema has a two-sections architecture where one describes the resource itself and the other describes its relationships to other resources. For example, the self describing section can include information such as which API version the endpoint supports, while the relationships section can indicate where to fine the address book of the person associated with the resource. On its own, XRD is mostly a schema, a document format, which can be obtained in many ways. For the use cases we focus on today such as OpenID, OAuth, Portable Contacts, OpenSocial, Activity Streams, etc., LRDD will be the primary delivery method.
- LRDD – the Link-based Resource Descriptor Discovery protocol (pronounced ‘lard’) is a collection of three link methods and a common relation type (‘describedby’). Together they are used to associate a descriptor to the resource it describes. In our focus, the descriptor format is XRD, but LRDD can be used with any other descriptor format such as POWDER (which in fact uses a subset of LRDD already). LRDD replaces the methods described in Yadis, by providing more standards-friendly substitutions.
- Links and /host-meta – the third layer includes a subset of the link framework. It consists of existing protocols such as the HTTP Link header and HTML <LINK> element together with a new ‘well-known-location’ solutions called /host-meta. The links layer provides a way to associate resources, for example, a web page with its stylesheet.
The next few posts will explain each component in detail.