The 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:
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.
Which leads to two XRDs, one for each calendar service:
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.
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.
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.