XRD Alignment with Link Syntax

XRD is a simple generic format for describing resources. Unlike past attempts, this time we got it right, and truly deliver on the promise of simple. In fact, the XRI TC spent the past year throwing features out if they were not supported by well-established use cases. Last month the specification reached the important milestone of a Committee Draft and was opened for public comments.While public review is open until January 6th (and we encourage feedback), we decide to publish a new working draft to address comments we already reach consensus on to help early adopters. The new draft, which the TC feels would be our last schema change, addresses all the comments received so far, but focuses on two comments:

  • The use of a new structure for the <Link> element and its deviation from common practice (i.e. ATOM, HTML, XHTML).
  • The limited and confusing nature of the <Type> element.

The new draft converts most of the <Link> child elements to attributes, and replaces the <Type> element with a <Property> element capable of expressing key/value pairs. I would like to thanks DeWitt Clinton and James Manger for their useful feedback.

An example XRD (updating the previous sneak-peak):

<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>



   <Property type='http://blgx.example.net/ns/version'>1.2</Property>
   <Property type='http://blgx.example.net/ns/ext'>lang</Property>

   <Link rel='author' type='text/html'
       <Title xml:lang='en-us'>Author Information</Title>

6 thoughts on “XRD Alignment with Link Syntax

  1. Can I ask a potentially stupid question: Why does XRD specify individual languages on elements? These are almost always served up by HTTP, which already sets a language header. Wouldn’t it be simpler to just create distinct XRD files for each language you cared about, and trust the server to deliver the right one?

    That would:

    i) reduce the size of each XRD file

    ii) make it easy to add localizations without changing a file (and thus its mod date)

    iii) simplify the schema

    iv) allow greater flexibility

    True, the price is that it is less DRY in that the documents would be largely redundant. But, given that you’re already allowing redundancy to simplify parsing, this would seem consistent with your state philosophy.

    Am I missing something?

    • I think you are overstating the “complexity”. XRD includes a single text element (<Title> which uses the existing and standard xml:lang attribute) for human consumption. There are many reason why the HTTP language content negotiation isn’t used including a much more complex deployment, the fact that most documents only support a single language, and because XRD does not depend on the transport for its meaning. XRDs can be delivered in many ways, and HTTP is only one of them.

  2. I’m happy to see the link element moving to be more like its equivalents in HTML and Atom. I still remain a little confused about the purpose of that “Title” element. Who is expected to display that title and in what context?

    I talked a little to Will about providing some information about the service provider that is providing specific services or providing the whole XRD so that consumers have something sensible to display in UI when describing who is providing a particular service. For ActivityStreams we have this ancillary (and sadly not quite finished) spec for an Atom extension: http://martin.atkins.me.uk/specs/activitystreams/provider

    That Property element seems a little strange. Why not just use elements from a foreign namespace, especially if the property “names” are going to be URIs anyway?

    • On the title part, it looks like a good thing to have, which usually would get this element kicked out, but HTML, HTTP, and ATOM have it. The most recent one is HTTP Link header which added support for multiple titles for different languages. Ultimately, it is the UI/protocol designer using this element who is going to decide how to best utilize it for human interaction.

      As for Property, we felt that providing an element for key/value pairs addresses pretty much every use case we have for resource properties. This solves previous limitations of the Type element. While XRD can be easily extended using XML namespaces, it is far more favorable by most developers to avoid it at all cost. This gives them a simple container for such data.

Comments are closed.