Tonight we had some quite interesting discussions going on in both the Second Life DataPortability meetup as well in the Skype chat of the Technical Action Group of the DataPortability project. Gabe Wachob joined us who is a member of the XRI TC and we discussed the issue of which service type to use within XRDS-Simple files. But first:
What is XRDS-Simple?
XRDS-Simple is sort of a service directory which lists service types (for now these types are more defined around OpenID as it’s mainly used there) and corresponding URIs. An example (Yahoo’s XRDS) looks as follows:
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns:openid="http://openid.net/xmlns/1.0"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://specs.openid.net/auth/2.0/server</Type>
<Type>http://specs.openid.net/extensions/pape/1.0</Type>
<URI>https://open.login.yahooapis.com/openid/op/auth</URI>
</Service>
</XRD>
</xrds:XRDS>
So what does that mean? It means that there is are services of the types http://specs.openid.net/auth/2.0/server and http://specs.openid.net/extensions/pape/1.0 (both part of OpenID) defined at the URI https://open.login.yahooapis.com/openid/op/auth. This means that any service looking for those services can parse the XRDS file, match the types and use the URI to use that service (in this case logging in the user via OpenID hence in this case it’s also called YADIS as it’s used to find an authentication endpoint for a given URL).
The file itself can be discovered in various ways. Either you give the URL directly, or it’s given as an HTTP header for a document or it’s a defined in the head-section of an HTML page (like RSS).
XRDS cannot only be used for YADIS though. In the DataPortability Project we recommend it’s use also to list all the other services for a user, e.g. where the profile is stored, contact lists or any other services we want to cover in the future.
What about other Service Types?
One question we in the DataPortability Project had was which service types are actually already defined and what the process is to define new ones, e.g. for defining that one endpoint is data marked up in hCard and another one in FOAF. We thought that it wouldn’t be a good idea to just define URIs which belong to namespaces we don’t control and we also didn’t want to use the dataportability.org namespace as this is not part of our mission. This is true even more as the goal should be to create a general directoy of service types also for services which are outside the scope of the DataPortability project.
Gabe then proposed to register a neutral domain for it which now became xrdstype.net.The goal is to put some sort of wiki or other structure there which describes these service types and links to their definitions. This is not supposed to be a list just for XRDS-Simple of course but for the „complete“ XRDS standard as well.
Service Types and MediaTypes
The XRDS-Simple specification not only defines service types but also media types. Here it’s important to discuss who combinations of these two can look like. The spec says:
- <Type>
- 0 or more per Service element with type xs:anyURI. The Type element describes the nature of the Resource, how it should be accessed, and the context in which it is selected. The value of the Type element MUST be an absolute URI. Each Service element MUST include at least one of either Type element or MediaType element, but MAY include any number of both.
- <MediaType>
- 0 or more per Service element with type xs:string. Describes the media-type of the content available at this Resource. The value MUST be a valid media-type as defined in [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” .). Each Service element MUST include at least one of either Type element or MediaType element, but MAY include any number of both.
So what if we want to describe that a ressource is in hCard format? (e.g. a profile). One idea which was floating around that we use a Type of „VCard“ (which might now be http://xrdstype.net/vcard) and a MediaType of „text/html+hcard“. But I am not sure if that has any advantages over using Type=http://xrdstype.net/microformats/hCard and MediaType=text/html.
Using VCard might make sense for profile data as both hCard and FOAF (with the VCard namespace) are used as some sort of transport format but this might not be true for other types such as contact lists. Here I would say that it’s Type=http://xrdstype.net/microformats/xfn or http://xrdstype.net/foaf/. Media Type can then be either text/html or text/xml.
This certainly should be discussed a bit more. The good thing is though that we can move forward and simply define the needed types as being part of xrdstype.net. We can then list those types we recommend for Data Portability in our wiki in the respective technical docs.
Update 2008/05/05 : What I didn’t find at first was a list of URIs for microformats. It can be found here. There is also some discussion happening now on the xrds-simple mailinglist. Mainly we wonder how Mime Types can be used as types or if they only make sense in the MediaType parameter. Gabe Wachob also explains the process for xrdstype.net in more detail in his blog.
Technorati Tags: dataportability, xrds, xrds-simple