Overview

As more services become Data Portability aware, the complexity of locating the information stores for a given user becomes ever more complex. Current practices include requesting that the user enter the details of their existing services (be that mail, social networking or otherwise), and that each recipient service has specific functionality for logging into those services and extracting the desired data - be that via Data Portability style formats, or simply through understanding of the target applications output mechanisms.

The service catalogue provides a mechanism to detail the services that a given user possesses, along with contact mechanisms for querying services to access the user's data on these services. This recommendation specifies the use of XRDS-Simple as the transport mechanism for this information. As this document is effectively a series of attributed links at heart, a number of alternatives exist, such as RDF or even raw HTML/XHTML. However, XRDS-Simple, and its parent format XRDS were designed with a fairly compatible goal of describing these resources, and has the benefit of providing a slightly more comprehensible schema than an RDF equivalent for the vast majority of developers that are currently unaware of RDF idioms.

Technology Purpose

As detailed in the introduction, the Service Catalogue  aims to provide an index of the services and the locations of the data for a given user. The service catalogue is implemented using the XRDS-Simple format, being developed by the group at http://groups.google.com/group/xrds-simple. XRDS Simple is a derivative of the XRDS standard, developed as part of the XRI specification set developed by OASIS for the extensible location and description of resources.

Selection Rationale

Again, as detailed in the overview, the Service Catalogue is essentially attributed data links, and could therefore be represented in any number of ways. XRDS Simple was selected due to its  specific relevancy to the task, and the relative simplicity of interpretation of the format.

Details of Adoption

Forming a vital component of the final approval process, this section should detail implementations that have adopted the technology, and therefore are showing that the technology has real-world applications and acceptance. 

Action Group Backing 

Members of the action groups that back this technology should be listed here, as a formal tracking of support for the recommendation.