XRD vs. XRDS, Side by Side Comparison

RingThe most significant difference between XRDS and XRD is who gets to describe related endpoints, and how this information is expressed in the descriptor document. Comparing the two formats side by side helps people familiar with XRDS understand the new architecture, but also demonstrate to new readers why the other approach is being deprecated.

It is important to note that while the <XRD> element appears in both formats, each uses a different XML namespace. The two elements share very little other than their name.

This is best explained with an example…

Joe has a profile page and would like to provide information on accessing his online calendars. Calendaring services related to a profile page are expressed differently in XRDS and XRD. Using a made-up calendar delegation specification, the descriptor documents (obtained using LRDD) would look something like this:

XRD

The resource’s XRD document provides a list of links, and expresses the relation of these links to the resource. A client parsing the XRD document makes its selection based on the relation information as well as the XRDs of the linked resources.

<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0′&gt;
<Subject>http://joe.example.org</Subject>
<Link rel=’http://example.net/cal/personal
href=’http://supercal.example.com/joe‘>
<Link rel=’http://example.net/cal/personal
href=’http://mycal.example.com/joe74‘>
</XRD>

Which leads to two XRDs, one for each calendar service:

<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0′&gt;
<Subject>http://supercal.example.com/joe</Subject>
<Property type=’http://example.net/cal/ver‘>1.0</Property>
</XRD>

<XRD xmlns=’http://docs.oasis-open.org/ns/xri/xrd-1.0′&gt;
<Subject>http://mycal.example.com/joe</Subject>
<Property type=’http://example.net/cal/ver‘>2.0</Property>
<Property type=’http://example.net/cal/ext&#8217;>freebusy</Property>
</XRD>

The profile page’s XRD only needs to maintain its own view of the related endpoints, describing each as ‘my personal calendar service’. It does not need keep up with the specifics of each calendar service such as its version and supported extensions.

A client consuming the XRD document first selects the calender service based on the profile page’s relation to each service. In this case, both services hold a personal calendar which does not help the client make a selection. If the client cares about the service-specific attributes, it must obtain the XRD for each service which adds additional round trips. If it does not care, it can choose either one since in this case the client did not express a preference using the <Link> ‘priority’ attribute.

XRDS

The resource’s XRDS provides a list of related services, and describes the properties of these related services. A client parsing the XRDS document makes its selection based on the information provided to it by the resource’s XRDS.

<XRDS>
<XRD xmlns=’xri://$xrd*($v*2.0)’>
<CanonicalID>http://joe.example.org</CanonicalID>
<Service>
<Type>http://example.net/cal/personal</Type>
<Type>http://example.net/cal/ver/1.0</Type>
<URI>http://supercal.example.com/joe</URI>
</Service>
<Service>
<Type>http://example.net/cal/personal</Type>
<Type>http://example.net/cal/ver/2.0</Type>
<Type>http://example.net/cal/ext/freebusy</Type>
<URI>http://mycal.example.com/joe74</URI>
</Service>
</XRD>
</XRDS>

The profile page’s XRDS includes both the subjective attributes of each service (‘my personal calendar’), and the objective attributes of the services (version, extensions). It requires the administrator of the profile page to keep the XRDS document in sync with the attributes of each service, if and when they change.

XRDS makes a consuming client’s job easier by directly including both the profile’s view and the service-specific attributes in one place. However, if the profile page’s administrator is different from that of each service (which in this case is very likely), the client cannot fully trust that the XRDS truly reflects the current state of each service. It is forced to simply ‘try it out’ and see if each service supports the version and extension indicated by the XRDS document. XRDS does not provide a way for each service to describe itself.

3 thoughts on “XRD vs. XRDS, Side by Side Comparison

  1. This is really helpful. I think I finally understand what you’re going for with XRD.
    The way I learned about XRDS was through the open stack – OpenID, PortableContacts, etc. In the case of delegated identity (or delegated anything) I see how XRD makes sense – because party A may not be as up to date as party B, so distributing responsibility makes sense.
    However, is that distribution necessary when the XRDS file is controlled by the service provider? As an example, if I ping “yahoo.com” I’ll get an XRDS that describes an OpenID provider rooted at a yahoo.com url. Presumably, since it’s the same company they would perform updates to both at the same time, and make sure they were in sync.
    Is there a way for a service owner to publish an XRD that describes attributes of the service similar to XRDS, and thus saves the client an extra round trip?

  2. Seconded. Apologies if I’m behind the curve here, but how would you describe XRD’s relationship to URI templates? Dependent on them as another standard, incorporated them pragmatically, or left them for an alternative?
    I posted a couple of questions / issues here at http://positiveincline.com/?p=6 – namely (1) whether the server really can prioritise templates on its own, and (2) about the status of URI templates generally. Any feedback (whether here or there) would be fantastic.

Comments are closed.