Da XRDS-Simple auch eine zentrale Rolle bei DataPortability spielen wird, hab ich mir das Format nochmal vorgenommen. (Im folgenden Text setze ich, der Einfachheit halber, XRDS mit XRDS-Simple gleich auch wenn es technisch nicht ganz korrekt ist)

XRDS-Simple-Large.png

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
https://notiz.blog/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.

3 thoughts on “XRDS-Simple, eine Einführung

  1. Vielen Dank für die verständliche Einführung. Gerade der Aspekt der Erkennung der verschiedenen Services scheint mir doch ein großer Vorteil zu sein.

    Ich kann dann auch delegieren, oder? Ich verlinke von meinem Blog auf ein XRDS Dokument bei Provider A (OpenID), der über ein XRDS-Dokument auf zwei weitere Provider B (APML) und C (OPML) verlinkt. Somit könnte niemand von meinem Blog aus erkennen, wo meine APML und OPML Files liegen. Sehe ich das falsch?

  2. Es funktioniert natürlich auch über eine „Art Delegation“ in dem man einfach auf einen externen Server verlinkt:

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

    Dieses XRDS-File könnte aber jeder Bot oder jede Person finden der diese URL (http://example.com/xrds) direkt aufruft, außer man schützt sie mit z.B. OAuth oder frägt sie über (OpenID) AttributeExchange ab…

    Im XRDS-File selbst sind dann alle möglichen Services wie z.B. APML, OPML, hCard, XFN usw. „verlinkt“.

    z.B.

    <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 priority="10">
          <Type>http://www.w3.org/2006/03/hcard</Type>
          <URI simple:httpMethod="GET">
            http://www.mybloglog.com/buzz/members/pfefferle/hcard
          </URI>
        </Service>
        <Service priority="20">
          <Type>http://gmpg.org/xfn/11</Type>
          <URI simple:httpMethod="GET">
            http://www.mybloglog.com/buzz/members/pfefferle
          </URI>
        </Service>
      </XRD>
    </XRDS>

    Ist es das was du gemeint hast?

  3. Ja, so in etwa meinte ich das. An den Schutz der URL habe ich noch gar nicht gedacht.

    Da bewegen wir uns auf ein kritisches Thema bzgl. Data Portability zu, denke ich. Wenn ich im Idealfall alles selbst hoste und die Daten (APML, OPML, Profil [hCard], Freunde [XFN],… Diensten nur bei Bedarf zur Verfügung stelle, bin ich natürlich auch für den Schutz selbst verantwortlich. Gleiches gilt auch OpenID und Delegation. Ich glaube, da müssen noch ein paar graue Zellen in Anspruch genommen werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.