XRDS-Simple ist in erster Linie eine einfache Form der Service-Discovery, von der Idee her ähnlich wie z.B. die Web Services Description Language (WSDL).
XRDS beschränkt sich, im Gegensatz zu dem wesentlich komplexeren WSDL, auf die Beschreibung der Service URLs/URIs und wie man sie nutzt (POST oder GET).

Vom Aufbau her ist XRDS-Simple dem YADIS Format (OpenID-Autodetection) sehr ähnlich:

<XRDS xmlns="xri://$xrds">
  <XRD xmlns:simple="http://xrds-simple.net/core/1.0"
          xmlns="xri://$XRD*($v*2.0)" version="2.0">
    <Type>xri://$xrds*simple</Type>
    <Service>
      <Type>http://example.net/some_type</Type>
      <URI simple:httpMethod="POST">

http://example.com/resource

      </URI>
    </Service>
  </XRD>
</XRDS>

Der wichtigste Teil eines Services ist der Type welcher den Typ der URI beschreibt und die URI welche beschreibt unter welcher URI der Service zu erreichen ist.

Ein paar Beispiele für ein paar klassische Services:

FOAF

type

http://xmlns.com/foaf/0.1/

url

http://www.mybloglog.com/buzz/members/pfefferle/foaf

hCard

type

http://purl.org/uF/hCard/1.0/

url

http://www.mybloglog.com/buzz/members/pfefferle/hcard

APML

type

http://www.apml.org/apml-0.6

url

http://notizblog.org/apml/

OPML

type

http://www.opml.org/spec2

url

http://ma.gnolia.com/opml/default/people/pfefferle

Neben dem <Type> kann für die URI auch noch ein <MediaType> (nichts anderes als der MIME-Type (RFC2046)) gesetzt werden, der beschreibt um was es sich bei dem Verlinkten handelt.

Beispiel: <MediaType>text/html</MediaType>

Mit diesem einfachen Prinzip lassen sich auf einfache Weise nahezu alle Services beschreiben.

Vorteile von XRDS-Simple? Meiner Meinung nach gibt es zwei wesentliche Gründe XRDS einzusetzen.

Einheitliche Erkennung

XRDS vereinfacht die automatische Service-Erkennung, da nur noch ein Meta-Tag interpretiert werden muss:

<meta http-equiv="X-XRDS-Location" content="http://example.com/xrds" />

statt jeder Meta-Tag einzeln:

<link rel="meta" type="text/xml" title="APML" href="..." />
<link rel="meta" type="text/xml" title="OPML" href="..." />

One file to detect them all

Information Hiding

Ein weiterer wesentlicher Aspekt der Autodetection ist die Sicherheit… nicht jeder möchte seine Attention-Daten (APML) oder seine hCard frei zur Verfügung stellen. Über XRDS-Simple ist es möglich, diese Informationen zu bündeln und z.B. nur über OpenID AX oder OAuth zugänglich zu machen.

Ein Beispiel dazu: XRDS-Simple als zentraler ServiceCatalogue

OAuth discovery

Der Vollständigkeit halber sollte man erwähnen dass XRDS-Simple eigentlich ein “Nebenprodukt” von OAuth Discovery ist.

The first draft of OAuth Discovery published four months ago started a dialog and was the main driver behind the development of XRDS-Simple. #

Mehr zu diesem Thema bei hueniverse oder Chris Messina.

Aber zuerst mal eine kurze Einführung. MicroID ist eine einfache Möglichkeit, den Besitz von Webseiten zu validieren.

MicroID enables anyone to claim verifiable ownership over content hosted anywhere on the web (social networking sites, discussion forums, blogs, etc.).

Das Prinzip ist einfach, es wird ein Hash-Wert aus zwei unterschiedlichen URLs (auch Pseudo-URLs wie z.B. “mailto:” oder “xmpp://” sind möglich) gebildet und als Metatag in die Webseite eingebunden.

hash = sha1(
    sha1( "mailto:mustermann@example.com" )
    +
    sha1( "http://www.example.com/" )
  )

Alternativ zu sha1 kann z.B. auch MD5 verwendet werden. Der Aufbau des Metatags sieht folgendermassen aus uri+uri:algo:hash

<meta name="microid"
  content="mailto+http:sha1:
    ba37d92454792b65838c9827a8d75171c7241924" />

Der Vorteil eines proprietären Formats im Gegensatz zu MicroID

Was die genauen Gründe dafür sind, dass myBlogLog ein eigenes Format verwendet weiß ich natürlich nicht, aber schaut man sich MicroID etwas genauer an, findet man doch einige kleine Problemchen.

Eigentlich ist es ja nur ein wirkliches Problem, und zwar die URL… Eine URL kann man auf zu viele verschieden Weisen schreiben, als dass sie eine valide ID abgeben könnte:

• http://example.com
• http://www.example.com
• http://example.com/

Zusammen mit der E-Mail – Adresse mustermann@example.com bekommt man drei verschiedene Hash-Werte:

• 19358536d8c443614bc7d861f4b050ee34a549b9
• 05c732700bfa89cd234bb7fc08cb673f7c0d88b8
• 9275b4dcd7cc2c997b2a5249420b422e937d36e0

Das heißt, es kommt immer darauf an wie der Benutzer seine URL bei einem entsprechenden Service angibt. Ist für den Metatag der Webseite http://example.com verwendet und beim Service http://www.example.com/ angegeben worden, kann die Webseite nicht verifiziert werden, da sich die Hash-Werte unterscheiden.

Lösungsvorschläge

Eine mögliche Lösung wäre alle denkbaren URLs auszuprobieren, was nicht sehr performant wäre und eine menge Zeit beanspruchen würde. Die (meiner Meinung nach) bessere Lösung wäre eine Art “service catalogue” an, in dem festgelegt ist wie z.B. die von myBlogLog verwendete MicroID-URL aussieht.

Ein Beispiel: http://www.mybloglog.com/buzz/members/Username/

Das Problem bezieht sich natürlich nur auf Services/Communities, bei denen man keinen Einfluss auf die MicroID hat. Bei persönlichen Weblogs ist das natürlich was anderes, da die URL und der Matatag vom Benutzer selbst angelegt werden.

Falls jemand noch nen tollen Lösungsvorschlag hätte wäre ich sehr dankbar, weil ich MicroID trotz allem gerne einsetzen würde… Das Prinzip ist einfach so schön simpel

TasteBroker is an experimental service that will generate a portable representation of your taste data (in the form of an APML file) from various web sources.

Bisher gibt es diesen Service für drei verschiedene Dienste: Last FM, Pandora und Del.icio.us.

Beispiele meiner Daten:

• http://TasteBroker.org/apml/last.fm/pfefferle
• http://TasteBroker.org/apml/web/pfefferle

Außerdem gibt es das WordPress Plugin jetzt auch für WordPress 2.x.