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 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>Code-Sprache: HTML, XML (xml)
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
- https://web.archive.org/web/20090825215938/http://www.mybloglog.com:80/buzz/members/pfefferle/foaf/
- hCard
-
- type
- http://purl.org/uF/hCard/1.0/
- url
- https://web.archive.org/web/20100413121636/http://www.mybloglog.com:80/buzz/members/pfefferle/hcard
- APML
-
- type
- https://github.com/apml/spec-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" />Code-Sprache: HTML, XML (xml)
statt jeder Meta-Tag einzeln:
<link rel="meta" type="text/xml" title="APML" href="..." />
<link rel="meta" type="text/xml" title="OPML" href="..." />Code-Sprache: HTML, XML (xml)
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.
