Glaner les descriptions de ressources des dialectes de langages (GRDDL)

Résumé

GRDDL est un mécanisme destiné à glaner des descriptions de ressources dans les dialectes des langages (N.d.T. Gleaning Resource Descriptions from Dialects of Languages). Cette spécification GRDDL introduit un balisage, fondé sur les standards existants, afin de déclarer qu'un document XML contient des données compatibles avec le cadre de descriptions de ressources (RDF) et afin d'associer des algorithmes, typiquement dans une représentation XSLT, pour en extraire les données.

Le balisage inclut un attribut qualifié par un espace de noms pour les documents XML d'utilisation générale et un lien d'association qualifié par un profil pour les documents XHTML. Le mécanisme GRDDL permet également de déclarer dans un document d'espace de noms XML (ou un document de profil XHTML) que chaque document associé à cet espace de noms (ou profil) contient des données à glaner, et d'associer un algorithme pour recueillir les données.

Une version préliminaire de cas d'utilisation GRDDL fournit des exemples motivants. Une introduction à GRDDL démontre le mécanisme sur des documents XHTML contenant des dialectes largement répandus appelés microformats. Un document de jeux d'essais GRDDL illustre les problèmes spécifiques de cette conception et fournit une documentation pour aider au développement expérimental d'agents connaissant GRDDL.

Statut de ce document

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ceci est une recommandation du W3C.

Ce document, qui a été revu par les membres du W3C, des développeurs de logiciels, d'autres groupes du W3C et des tiers intéressés, a été approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui peut servir de document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation consiste à attirer l'attention sur la spécification et à promouvoir son large déploiement. Cela participe à améliorer la fonctionnalité et l'interopérabilité du Web.

Les commentaires à propos de ce document sont à faire sur la liste de diffusion public-grddl-comments@w3.org, dont les archives sont publiques.

Ce document a été produit par le groupe de travail GRDDL, qui fait partie de l'activité Semantic Web du W3C. La première parution du document comme version de travail a eu lieu le 24 octobre 2006, et le groupe de travail a traité beaucoup de commentaires reçus et de problèmes depuis. Les assertions normatives sont marquées de cette manière.

Le rapport de mise en œuvre du groupe de travail démontre que les objectifs d'interopérabilité des mises en œuvre, fixés dans la mouture de la recommandation candidate de ce document de mai 2007, ont été atteints.

GRDDL contribut à résoudre les problèmes d'architecture Web tels que RDFinXHTML-35, namespaceDocument-8 et xmlFunctions-34, ainsi que les problèmes ajournés par le groupe de travail RDF Core tels que rdfms-validating-embedded-rdf et faq-html-compliance. En particulier, le groupe de travail GRDDL a ajourné le problème issue-faithful-infoset et attend de la résolution du problème TAG xmlFunctions-34 qu'elle fournisse plus d'éclaircissements et une orientation.

Ce document a été produit par un groupe agissant sous couvert de la politique de brevets du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets faites en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Toute personne ayant connaissance réelle d'un brevet qu'elle estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.

L'annexe des problèmes qui faisait partie de cette version a été déplacée vers une liste de problèmes du groupe de travail, notamment : issue-whichlangs, issue-output-formats, issue-base-param, issue-tx-element, issue-html-nsdoc, issue-faithful-infoset, issue-mt-ns, issue-conformance-labels, issue-http-header-links

Table des matières

• 1. Introduction
• 2. Ajouter du GRDDL à du XML bien formé
• 3. GRDDL pour les espaces de noms XML
• 4. Utiliser GRDDL avec du XHTML valide
• 5. GRDDL pour les profils HTML
• 6. Les transformations GRDDL
• 7. Les agents connaissant GRDDL
• 8. Réflexions autour de la sécurité
• 9. Le vocabulaire GRDDL
• 10. Références

• Annexe : Transformations de style contre extraction de données
• Annexe : Réflexions autour de l'identificateur IRI de base
• Annexe : Remerciements et historique des changements

• Annexe : À propos des règles mécaniques

1. Introduction : les données et les documents

Beaucoup de langages spécifiques à des domaines (dialectes) sont utilisés en pratique dans la multitude de documents XML sur le Web. Il existe des dialectes de XHTML, XML et RDF qui servent à tout représenter, de la poésie à la prose, des bons de commande aux factures, des feuilles de calcul aux bases de données, des schémas aux écritures, et des listes associées aux ontologies.

Quoique cette largeur d'expressions soit très libératrice, inspirant de nouveaux dialectes pour représenter des informations, elle peut constituer une barrière à la compréhension entre des domaines ou des champs différents. Par exemple, comment un logiciel découvre-t-il l'auteur d'un poème, d'une feuille de calcul et d'une ontologie ? Et comment le logiciel peut-il déterminer si les auteurs de chaque ne font en réalité qu'un ?

Voici des exemples de la façon dont on pourrait décrire la même œuvre musicale dans des dialectes XML différents :

iTunes Music Library

<key>Artist</key>
  <string>The Jimi Hendrix Experience</string>
<key>Album</key>
  <string>Are You Experienced?</string>

Audioscrobbler

<album>
    <artist mbid="">The Jimi Hendrix Experience</artist>
    <name>Are You Experienced?</name>
...
</album>

Atom

<entry ... >
<title>Are You Experienced?</title>
<author>
<name>The Jimi Hendrix Experience</name>
</author>
...
</entry>

Open Office

<office:document-meta ... >
<office:meta>
<dc:title>Are You Experienced?</dc:title>
  <meta:initial-creator>
  The Jimi Hendrix Experience
  </meta:initial-creator>
<dc:creator>The Jimi Hendrix Experience</dc:creator>
</office:meta>
</office:document-meta>

Bien que les exemples précédents soit à l'évidence des codages de la même information, il n'en demeure pas moins que manquent des mécanismes clairs par lesquels un logiciel seraient capable de déterminer cette relation.

Les descriptions de ressources

Le cadre de description de ressources [RDFC04] fournit un standard pour faire des déclarations à propos de ressources sous la forme d'expressions sujet-prédicat-objet. Une représentation du fait que l'interprète de « Are You Experienced? » est « The Jimi Hendrix Experience » en RDF serait celle d'un triplet dont le sujet est « Are You Experienced », le prédicat est « a pour interprète » et l'objet est « The Jimi Hendrix Experience ». Le prédicat « a pour interprète » exprime une relation entre le sujet (Are You Experienced?) et l'objet (The Jimi Hendrix Experience). Utiliser des adresses URI pour identifier singulièrement l'album, l'interprète et même la relation faciliterait la conception des logiciels, car ce n'est pas tout le monde qui connaît « The Jimi Hendrix Experience » ou même épelle son nom avec régularité.

Voici les informations contenues dans les fragments XML précédents, exprimées cette fois en RDF:

<rdf:RDF
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/">

  <rdf:Description rdf:about=
"http://musicbrainz.org/mm-2.1/album/6b050dcf-7ab1-456d-9e1b-c3c41c18eed2">
    <dc:title>Are You Experienced?</dc:title>
    <foaf:maker>
      <foaf:Agent rdf:about=
  "http://musicbrainz.org/mm-2.1/artist/33b3c323-77c2-417c-a5b4-af7e6a111cc9">
        <foaf:name>The Jimi Hendrix Experience</foaf:name>
      </foaf:Agent>
    </foaf:maker>

  </rdf:Description>
</rdf:RDF>

Les entités (les ressources sujet et objet) et la relation (prédicat) sont identifiées par des adresses URI sans équivoque.

Remarquez que GRDDL suit HTML 4, RDF et XML Schema, à utiliser des identificateurs de resources internationalisés, c'est-à-dire des adresses IRI [RFC3987]. Tandis que cette spécification, dans un usage informel, emploie le terme plus familier « URI » de façon interchangeable avec celui normalisé plus récemment « IRI », les règles formelles utilisent les termes pertinents de manière exacte.

Les éditeurs du code XML ci-dessus pourraient tout aussi bien fournir les mêmes données en RDF en utilisant RDF/XML ou l'une des autres syntaxes RDF. GRDDL offre un mécanisme relativement économe pour amorcer (N.d.T. bootstrapping) du contenu RDF depuis des dialectes XML uniformes, en remplaçant le fardeau de la formulation RDF par la création d'algorithmes de transformation spécifiques pour chaque dialecte.

GRDDL fonctionne en associant des transformations à un document individuel soit par inclusion directe de références, soit indirectement au travers de documents de profils et d'espaces de noms. Les créateurs de contenus peuvent sélectionner les transformations de production RDF depuis leurs contenus et utiliser GRDDL pour les appeler.

2. Ajouter du GRDDL à du XML bien formé

La forme générale d'association d'un lien de transformation GRDDL à un document XML bien formé est l'ajout à l'élément racine du document d'une déclaration d'espace de noms grddl et d'un attribut grddl:transformation dont la valeur est une référence IRI (ou une liste de références IRI) qui pointent vers des scripts ou des programmes exécutables ayant vocation à transformer le document source en RDF. Cette méthode convient pour tous les dialectes XML qui peuvent recevoir un attribut supplémentaire qualifié par un espace de noms sur l'élément racine.

Par exemple, ce document XML situé à http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.html est lié à deux transformations GRDDL :

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:grddl='http://www.w3.org/2003/g/data-view#'
      grddl:transformation="glean_title.xsl
			http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl"
 >
<head>
<title>Are You Experienced?</title>
[...]
</html>

1. Il est lié à la transformation identifiée par http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl ;
2. Pour résoudre l'adresse URI relative glean_title.xsl en une forme absolue, nous utilisons l'adresse URI de base de cet élément XML, c'est-à-dire http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.html. Le document est alors lié aussi à la transformation GRDDL identifiée par la forme absolue http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl.

Extraction des valeurs de titre et d'auteur

(svg)

Comme vous le verrez dans les sections suivantes, il existe d'autres méthodes pour ajouter du GRDDL aux documents HTML, conçues spécialement pour tirer profit des capacités existantes de HTML et surmonter avec elles les contraintes imposées par les définitions de type de document (DTD) XML de certains dialectes de HTML. Cf. les sections « Utiliser GRDDL avec du XHTML valide » et « GRDDL pour les profils HTML ».

La définition formelle de ce balisage est données ci-dessous. Chaque règle se présente dans une version mécanique informative avec les prémisses et la conclusion écrits comme des motifs graphiques SPARQL [SPARQL]. Cf. l'annexe « À propos des règles mécaniques » pour les liaisons de préfixes d'espace de noms et plus d'explications. Elles sont incluses pour ceux des lecteurs qui les trouvent utiles. Les autres sont invités à les ignorer.

/*/@*[local-name()="transformation"
  and namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]

(?N "/*") gspec:xpath ?E.
(?N """/*/@*[local-name()="transformation" and
    namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]""")
   gspec:xpath [ fn:string ?V].
?V fn:normalize-space ?Vnorm.
(?Vnorm "[ \t\r\n]+") fn:tokenize [
  list:member ?REF ].
?E fn:base-uri ?BASE.
(?REF ?BASE) fn:resolve-uri ?TXURI.
?TX log:uri ?TXURI.

?N grddl:transformation ?TX.

Soit le document XML ci-dessus en entrée, la transformation glean_title.xsl produit le document RDF/XML suivant :

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="">
    <dc:title>Are You Experienced?</dc:title>
  </rdf:Description>
</rdf:RDF>

Le graphe sérialisé par ce document est un résultat GRDDL de la ressource identifiée par http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.html. Remarquez que cette sérialisation du graphe contient une adresse URI relative (comme valeur de l'attribut rdf:about). L'adresse IRI de base pour interpréter les références IRI relatives dans une sérialisation d'un graphe produit par une transformations GRDDL est l'adresse IRI de base du document source.

La ressource glean_title.xsl définit une fonction des nœuds d'un document XPath vers des documents RDF/XML, et donc vers des graphes RDF : cette fonction est appelée la propriété de transformation du document XSLT. Cf. la section « Les transformations GRDDL » pour plus de détails.

La règle générale d'utilisation de GRDDL avec du XML bien formé est la suivante :

?IR log:uri [ fn:doc ?R ].
?R grddl:transformation [ grddl:transformationProperty ?TP ].
?R ?TP ?G.

?IR grddl:result ?G .

La ressource titleauthor.html a un autre résultat GRDDL via la transformation getAuthor.xsl. Ces résultats peuvent fusionner en un autre par cette règle :

?IR grddl:result ?F, ?G.
(?F ?G) log:conjunction ?H.

?IR grddl:result ?H.

3. Utiliser GRDDL avec des documents d'espaces de noms XML

On peut associer des transformations non seulement à des documents individuels mais aussi à des dialectes entiers partageant un espace de noms XML. Toute ressource récupérable à partir d'une adresse URI d'espace de noms est un document d'espace de noms (cf. la section 4.5.4. Namespace documents de [WEBARCH]). Par exemple, un document d'espace de noms peut avoir une représentation XML Schema, ou RDF Schema, ou même les deux, en utilisant une négociation de contenu.

Pour associer une transformation GRDDL à un dialecte entier, placez une propriété grddl:namespaceTransformation dans un résultat GRDDL du document d'espace de noms.

Par exemple, voyez cette politique de confidentialité écrite en P3Q, un analogue imaginaire de P3P [P3P] :

<POLICIES xmlns="http://www.w3.org/2004/01/rdxh/p3q-ns-example">
	<EXPIRY max-age="604800"/>
...

Le document d'espace de noms de P3Q relie la transformation grokP3Q.xsl à tous les documents P3Q :

<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dataview="http://www.w3.org/2003/g/data-view#">
 <rdf:Description rdf:about="http://www.w3.org/2004/01/rdxh/p3q-ns-example">
   <dataview:namespaceTransformation
       rdf:resource="http://www.w3.org/2004/01/rdxh/grokP3Q.xsl"/>
 </rdf:Description>
</rdf:RDF>

C'est-à-dire que tous les documents dont le nom d'espace de noms racine est ...p3q-ns-example ont implicitement pour transformation GRDDL grokP3Q.xsl, comme illustré dans ce diagramme :

Transformation appliquée à l'espace de noms
(svg)

Certains documents d'espaces de noms, tel le document d'espace de noms XHTML http://www.w3.org/1999/xhtml, sont très souvent référencés. Si les agents connaissant GRDDL devaient les récupérer à chaque fois qu'ils traitent les documents s'y rapportant, les serveurs origines de ces documents d'espaces de noms seraient surchargés. Les agents connaissant GRDDL ne devraient donc pas récupérer ces documents d'espaces de noms à chaque appel mais garder un cache ou une mémoire locale des transformations dont les documents réclament l'application. Pour éviter une représentation erronée des informations publiées, les agents connaissant GRDDL devraient s'assurer de la mise à jour de cette mémoire locale et devraient offrir aux utilisateurs la possibilité de configurer ou de désactiver le cache. Cf. également la section « 3.1. Utiliser une adresse URI pour accéder à une ressource » de [WEBARCH].

Le cas général des transformations d'espaces de noms est le suivant :

?NSDOC log:uri ?NS;
   grddl:result [
     log:includes [
       rdf:subject ?NSDOC;
       rdf:predicate grddl:namespaceTransformation;
       rdf:object ?TX]].
?IR log:uri [ fn:doc ?NODE].
(?NODE "/*") gspec:xpath ?E.
?E fn:namespace-uri ?NS.

?NODE grddl:transformation ?TX.

Remarquez que comme cas de base, le résultat de l'analyse d'un document RDF/XML est un résultat GRDDL de ce document :

?IR log:uri [ fn:doc [ gspec:rdfParse ?G ] ].

?IR grddl:result ?G.

Bien que le type de média application/rdf+xml soit une indication que le document est de type RDF/XML, notez que la section « 7.2.1 Début de la grammaire » de [RDFX] laisse le champ libre aux « autres méthodes » qui peuvent identifier un document RDF/XML. Pour les besoins de la règle précédente, un élément racine dont le nom local est RDF et dont l'adrese URI d'espace de noms est http://www.w3.org/1999/02/22-rdf-syntax-ns# constitue l'une de ces méthodes. Pour un exemple à-propos, cf. le cas d'utilisation grddlonrdf-xmlmediatype.

Exemple : Utiliser GRDDL avec un document d'espace de noms XML Schema

Un lien de transformation d'espace de noms peut être découvert en transformant le document d'espace de noms même. Cela signifie que les documents d'espaces de noms n'ont pas besoin d'être écrits directement en RDF/XML.

Soit un bon de commande ayant un document d'espace de noms représentés en XML Schema, où le schéma comporte un attribut data-view:transformation qui concède l'extraction de déclarations incluant des déclarations namespaceTransformation :

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns="http:.../Order-1.0"
            targetNamespace="http:.../Order-1.0"
            version="1.0"
            ...
            xmlns:data-view="http://www.w3.org/2003/g/data-view#"
            data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl" >
    <xsd:element name="Order" type="OrderType">
    <xsd:annotation 
      <xsd:documentation>Cet élément est l'élément racine.</xsd:documentation>
    </xsd:annotation>
                 ...
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
	<rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
	  <data-view:namespaceTransformation
	      rdf:resource="grokPO.xsl" />
	</rdf:Description>
      </rdf:RDF>
    </xsd:appinfo>
  </xsd:annotation>
...

Chaque bon de commande utilisant ce schéma comme document d'espace de noms est lié à la transformation grokPO.xsl, comme illustré ci-dessous :

Utiliser GRDDL avec un schéma XML

(svg)

4. Utiliser GRDDL du XHTML valide

Pour tirer profit de la syntaxe XHTML fondée sur une définition DTD [XHTML], laquelle empêche d'utiliser les attributs issus d'espaces de noms étrangers, nous utiliserons http://www.w3.org/2003/g/data-view comme profil de métadonnées (cf. la section « 7.4.4.3 Les profils de métadonnées » de [HTML4]).

La forme générale pour ajouter une assertion GRDDL à un document XHTML valide est de définir le profil GRDDL dans l'attribut profile de l'élément head, et de donner la valeur transformation à l'attribut rel d'un élément link (ou a) dont la valeur de l'attribut href est l'adresse IRI d'un script ou d'un programme exécutable ayant vocation à transformer le document source en RDF. Cette méthode convient pour les documents XHTML valides contraints par une définition DTD XML.

Un exemple de transformation META Dublin Core

Pour l'exemple, ce document suit les conventions du document [RFC2731]. Il utilise explicitement le profil GRDDL et lie à une transformation XSLT vers RDF/XML pour signaler que la transformation est une interprétation fidèle :

<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://www.w3.org/2003/g/data-view">
    <title>Un document</title>

    <link rel="transformation"
       href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl" />
    <meta name="DC.Subject"
       content="ADAM; Simple Search; Index+; prototype" />
    ...
  </head>
  ...
</html>

Le diagramme ci-dessous montre le document source, la transformation dc-extract.xsl et le résultat GRDDL :

Décoder des métadonnées HTML vers RDF

(svg)

Voici de quoi ont l'air les données en RDF/XML:

<rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about="">
    <dc:subject>ADAM; Simple Search; Index+; prototype</dc:subject>
  </rdf:Description>
</rdf:RDF>

Transformations multiples en XHTML

Un document XHTML peut être conforme à plusieurs dialectes simultanément et lier à plusieurs transformations GRDDL. Toutefois, puisque l'attribut href des éléments link et a n'accepte qu'une seule référence IRI, il faut utiliser plusieurs instances de ces éléments pour faire valoir plusieurs liens :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
  <title>La page d'accueil de Joe Lambda [un exemple de RDF dans XHTML]</title>

  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
  <link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />
...

Transformations multiples

(svg)

?N gspec:profileName "http://www.w3.org/2003/g/data-view".
(?N
""".//*[namespace-uri()="http://www.w3.org/1999/xhtml" and
        (local-name() = "a"
         or local-name() = "link")"""
) gspec:xpath ?E.
(?E "@rel") gspec:xpath [ fn:string [
   fn:normalize-space ?E_REL ]].
(?E_REL "[ \t\r\n]+") fn:tokenize [
 list:member "transformation" ].
(?E "@href") gspec:xpath [ fn:string ?T_REF ].
?E gspec:htmlBase ?BASE.
(?T_REF ?BASE) fn:resolve-uri ?TURI.
?T log:uri ?TURI.

?N grddl:transformation ?T.

(?N
 """
*[local-name()="html" and
  namespace-uri()="http://www.w3.org/1999/xhtml"] /
 *[local-name()="head" and
   namespace-uri()="http://www.w3.org/1999/xhtml"]""")
 gspec:xpath ?E.
(?E "@profile") gspec:xpath [ fn:string ?V ].
?E fn:base-uri ?BASE.
?V fn:normalize-space ?Vnorm.
(?Vnorm "[ \t\r\n]+") fn:tokenize [  list:member ?P_REF ].
(?P_REF ?BASE) fn:resolve-uri ?PROFID.

?N gspec:profileName ?PROFID.

5. GRDDL pour les profils HTML

XHTML fournit le mécanisme des profils pour lier à la signification des propriétés et à l'ensemble de leurs valeurs légales. Comme pour les documents d'espaces de noms, on peut effectivement écrire un document de profil en utilisant du XHTML avec des déclarations RDF incorporées et une transformation GRDDL pour extraire la définition des termes applicables. Ces termes peuvent alors être utilisés dans un document XHTML pour véhiculer une signification dépendant d'un profil. Comme expliqué dans la section « Utiliser GRDDL avec du XHTML valide », le profil GRDDL peut servir avec des documents XHTML pour appliquer une sémantique GRDDL sur les éléments link dont l'attribut rel vaut transformation. Ce mécanisme très puissant et flexible s'intègre bien avec les profils de microformats [MF-RDF-FAQ] qui se superposent au balisage HTML normalement à sémantique pauvre.

Le diagramme suivant montre un document XFN [XFN], friends.html, associé indirectement à la transformation grokXFN.xsl via un profil XFN.

Indirection via un profil

(svg)

Ajouter une assertion profileTransformation GRDDL à un document de profil ressemble beaucoup à ajouter une assertion namespaceTransformation à un document d'espace de noms. Pour un dialecte défini par un document de profil XHTML valide, ajoutez profile="http://www.w3.org/2003/g/data-view" à l'élément head et faites un lien de type profileTransformation vers la transformation du dialecte.

La règle générale est la suivante :

?PDOC log:uri ?PNAME;
   grddl:result [
     log:includes [
       rdf:subject ?PDOC;
       rdf:predicate grddl:profileTransformation;
       rdf:object ?TX]].
?IR log:uri [ fn:doc ?NODE].
?NODE gspec:profileName ?PNAME.

?NODE grddl:transformation ?TX.

6. Les transformations GRDDL

Comme indiqué précédemment, chaque transformation GRDDL définit une propriété de transformation, c'est-à-dire une fonction de nœuds de documents XPath vers des graphes RDF. Cette fonction n'est pas forcément totale, elle peut avoir un ensemble de définition plus petit que l'ensemble de tous les nœuds des documents XML. Par exemple, on peut utiliser xsl:message avec terminate="yes" pour signaler que l'entrée est extérieure à l'ensemble de définition de la transformation.

Les créateurs de transformations devraient proposer des représentations dans les formats courants. Au moment de la rédaction de ce document, XSLT version 1 [XSLT1] est le format le plus courant utilisé par les agents connaissant GRDDL, quoique le déploiement de XSLT2 [XSLT2] progresse. Techniquement, bien quon puisse utiliser JavaScript, C ou virtuellement n'importe quel autre langage de programmation pour exprimer des transformations pour GRDDL, XSLT est spécifiquement conçu pour exprimer du XML en transformations XML, et il possède de bonnes caractéristiques de sécurité ; XQuery offrent des caractéristiques similaires à XSLT, mais l'utilisation de XQuery dans les mises en œuvre GRDDL est moins courante à l'heure actuelle.

?RDFXML gspec:rdfParse ?G.
(?TXNODE ?R) gspec:resultTree ?RDFXML.
?TXDOC grddl:transformationProperty ?TP;
  log:uri [fn:doc ?TXNODE].

?R ?TP ?G

La règle précédente couvre le cas d'une propriété de transformation qui relie un nœud de document XPath à un graphe RDF via un document RDF/XML. Les transformations peuvent emprunter d'autres mécanismes non définis. Par exemple, cf. le test #atomttl1, dans lequel l'attribut media-type de l'élément xsl:output porte une valeur "text/rdf+n3" pour indiquer un autre type de média que "application/rdf+xml". Les agents GRDDL capables de traiter ce type de média peuvent alors produire un graphe RDF conformément au type de média. Les transformations non-XSLT peuvent indiquer le graphe RDF d'une autre façon non définie.

7. Les agents connaissant GRDDL

Un agent connaissant GRDDL est un module logiciel qui calcule les résultats GRDDL de ressources d'information.

Par exemple, un service d'interrogation SPARQL pourrait utiliser un agent connaissant GRDDL pour collecter des données RDF. Ou bien un navigateur Web pourrait faire office d'agent connaissant GRDDL dans le but de collecter des agendas et des coordonnées. La politique appropriée, à savoir quels résultats calculer et quand les calculer, implique d'attendre un signal de l'utilisateur, plus vraisemblablement dans le cas du navigateur Web que dans celui du service d'interrogation.

Remarquez que la découverte par un document d'espace de noms ou de profil est récursive. Il y a lieu de détecter les boucles dans la structure de l'espace de noms ou du profil pour éviter une récursion infinie.

[00:00.000 - client connection from 127.0.0.1:39645]
GET http://www.w3.org/2003/g/po-doc.xml HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html

[00:00.055 - server connected]
HTTP/1.1 200 OK
Last-Modified: Tue, 07 Dec 2004 22:59:02 GMT
Content-Length: 1302
Content-Type: application/xml; qs=0.9

<purchaseOrder orderDate="1999-10-20"
   xmlns="http://www.w3.org/2003/g/po-ex">
   <shipTo country="US">
      <name>Alice Smith</name>
      <street>123 Maple Street</street>
...

[00:00.000 - client connection from 127.0.0.1:39647]
GET http://www.w3.org/2003/g/po-ex HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html

[00:00.051 - server connected]
HTTP/1.1 200 OK
Content-Location: po-ex.xsd
Last-Modified: Tue, 07 Dec 2004 23:18:25 GMT
Content-Length: 2624
Content-Type: application/xml; qs=0.9

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
        xmlns:po="http://www.w3.org/2003/g/po-ex"
        targetNamespace="http://www.w3.org/2003/g/po-ex"
        elementFormDefault="qualified"
        attributeFormDefault="unqualified"

   xmlns:data-view="http://www.w3.org/2003/g/data-view#" 
   data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl"
  >

  <xs:annotation>
    <xs:appinfo>
      <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
        <rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
          <data-view:namespaceTransformation
              rdf:resource="grokPO.xsl" />
        </rdf:Description>
      </rdf:RDF>
    </xs:appinfo>
  </xs:annotation>
...

00:00.000 - client connection from 127.0.0.1:39649]
GET http://www.w3.org/2003/g/embeddedRDF.xsl HTTP/1.1
Host: www.w3.org
Accept: application/xml

[00:00.054 - server connected]
HTTP/1.1 200 OK
Last-Modified: Wed, 23 Mar 2005 18:49:12 GMT
Content-Length: 797
Content-Type: application/xml; qs=0.9

<xsl:transform
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
...

<rdf:RDF
   xmlns:data-view="http://www.w3.org/2003/g/data-view#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <rdf:Description rdf:about="http://www.w3.org/2003/g/po-ex">
    <data-view:namespaceTransformation rdf:resource="http://www.w3.org/2003/g/grokPO.xsl"/>
  </rdf:Description>
</rdf:RDF>

[00:00.000 - client connection from 127.0.0.1:39651]
GET http://www.w3.org/2001/XMLSchema HTTP/1.1
Host: www.w3.org
Accept: application/rdf+xml,application/xml,text/xml,application/xhtml+xml,text/html
If-modified-since: Fri, 16 Dec 2005 14:19:38 GMT

[00:00.047 - server connected]
HTTP/1.1 304 Not Modified
Content-Location: XMLSchema.html
Expires: Wed, 07 Feb 2007 15:09:29 GMT
Cache-Control: max-age=21600
Vary: negotiate, accept, accept-charset

[00:00.000 - client connection from 127.0.0.1:39653]
GET http://www.w3.org/2003/g/grokPO.xsl HTTP/1.1
Host: www.w3.org
Accept: application/xml

[00:00.048 - server connected]
HTTP/1.1 200 OK
Last-Modified: Tue, 07 Dec 2004 23:33:28 GMT
Content-Length: 1739
Content-Type: application/xml; qs=0.9

<xsl:transform
    version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:po="http://www.w3.org/2003/g/po-ex"
    xmlns:poF="http://www.w3.org/2003/g/po-ex#"
    >

<xsl:output method="xml" indent="yes" />

<div xmlns="http://www.w3.org/1999/xhtml">
<h1>grokPO.xsl -- interpret purchase order format as RDF</h1>
...

<rdf:RDF
   xmlns:poF="http://www.w3.org/2003/g/po-ex#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>
  <rdf:Description rdf:nodeID="hOhqYGhx9">
    <poF:city>Mill Valley</poF:city>
    <poF:state>CA</poF:state>
    <poF:zip>90952</poF:zip>
    <poF:street>123 Maple Street</poF:street>
    <poF:name>Alice Smith</poF:name>
  </rdf:Description>
...

8. Réflexions autour de la sécurité

L'exécution de langages de programmation d'utilisation générale comme interpréteurs des transformations présente des risques sérieux pour la sécurité. On conseille aux concepteurs d'agents connaissant GRDDL de ne pas envoyer simplement les transformations GRDDL à des interpréteurs « prêts à l'emploi ». Bien que passer des documents provenant de sources de confiance au travers d'une transformation GRDDL soit habituellement sûr, les développeurs devraient tenir compte de ce qui suit avant d'ajouter la capacité d'exécuter des transformations GRDDL arbitraires reliées à des documents Web quelconques.

GRDDL, comme beaucoup de technologies Web, repose fondamentalement sur la résolution d'adresses URI. Les créateurs de transformations GRDDL sont invités à ne pas employer d'opérations sur les adresses URL potentiellement dangereuses, parce qu'elles sont vraisemblablement disponibles dans les mises en œuvres GRDDL sécurisées. Il est conseillé pour les programmes exécutant des transformations GRDDL soit de désactiver complètement toutes les opérations URL à risques, soit de faire très attention de ne pas déléguer d'autorité spéciale à leur exécution. En particulier, les opérations de lecture ou d'écriture des adresses URL sont exécutées plus sûrement avec les privilèges associés à un tiers non vérifié plutôt qu'avec ceux de l'utilisateur courant. Ces désactivation et/ou vérification devraient avoir entièrement lieu hors d'atteinte du langage de transformation même ; il faudrait s'assurer qu'il n'existe aucun moyen de réactiver les versions intégrales de ces opérateurs.

Le reste de cette section souligne quelques problèmes possibles, probablement pas tous, dans l'exécution des transformations GRDDL, en particulier pour les transformations en XSLT.

1. L'utilisation sans restriction de GRDDL laisse les transformations non vérifiées accéder à des adresses URL pour lesquelles l'utilisateur a permission de lecture ou d'écriture, que l'auteur de la transformation n'a pas. Cela concerne tout particulièrement les adresses URL du schéma file:, mais beaucoup d'autres schémas sont également touchés. Le code non vérifié, une fois lus les documents auxquels l'auteur n'avait pas droit d'accès, peut transmettre le contenu des documents à des serveurs Web arbitraires, qui peut être passé aux serveurs en le codant dans une adresse URL ;
2. Les opérations à risques dans le langage XSLT comprennent, entre autres, celles impliquant la récupération d'une adresse URL : document(), doc(), unparsed-text() et unparsed-text-available(), et xsl:result-document impliquant d'écrire vers une adresse URL. Les opérations xsl:include et xsl:import présentent moins de risques si elles sont traitées avant l'exécution de la transformation plutôt que pendant ;
3. Certaines mises en œuvre de langages de transformation peuvent offrir des méthodes pour charger et exécuter du code d'un autre langage de programmation. Par exemple, une mise en œuvre XSLT peut offrir une méthode pour exécuter du code Java. Ces dispositifs sont évidemment ouverts aux abus. On conseille aux créateurs de transformations GRDDL de ne pas utiliser ces fonctionnalités. Outre d'être propres à une mise en œuvre, elle ne seront vraisemblablement pas disponibles dans les mises en œuvre sécurisées du langage de transformation. En cas de rencontre dans un programme exécutant des transformations GRDDL, l'utilisation de tels opérateurs devraient être empêchée ;
4. Les mises en œuvre XSLT proposent souvent leurs propres extensions. On conseille aux créateurs de transformations GRDDL de ne pas les utiliser car leur présence n'est pas garantie dans toutes les mises en œuvre. Un programme exécutant des transformations GRDDL devrait s'assurer que les extensions sont sûres et ne présentent aucune menace ;
5. Il est possible d'écrire des transformations qui consomment des ressources systèmes excessives ou bouclent à l'infini. Les transformations de ces types ont le potentiel de nuire lorsqu'elles sont envoyées à des destinataire qui ne se méfient pas. On conseille aux créateurs de transformations de ne pas en construire ou d'en disséminer. Un programme exécutant des transformations GRDDL devrait fournir des mécanismes appropriés pour abandonner le traitement après un délai raisonnable. De plus, un programme GRDDL devrait être limité à seulement consommer une quantité raisonnable d'une ressource système donnée ;
6. Enfin, il peut exister des bogues dans certains interpréteurs d'un langage de transformation, susceptibles d'être exploités pour accéder sans autorisation au système d'un destinataire. À part tenir compte de cette possibilité, il n'y a rien d'autre à faire que de corriger à propos ces bogues au fur et à mesure de leur découverte.

9. Le vocabulaire GRDDL

Voici un extrait du document de profil/d'espace de noms GRDDL :

Ce document (http://www.w3.org/2003/g/data-view) est un profil de métadonnées au sens de la spécification HTML, d'après la section « 7.4.4.3 Les profils de métadonnées ».

Le terme suivant est introduit ici comme nom de relation de lien XHTML et nom de propriété RDF :

• transformation : relie un document source à une transformation, représentée habituellement en XSLT, reliant la syntaxe du document source à la syntaxe de graphe RDF. domain : RootNode ; range : Transformation

Les termes suivants sont introduits ici comme propriétés RDF :

• namespaceTransformation : relie un espace de noms à une transformation pour tous les documents dans cet espace de noms. range : Transformation
• profileTransformation : relie un document de profil à une transformation pour tous les documents comportant ce profil. range : Transformation
• result : un graphe RDF obtenu depuis une ressource d'information en interprétant directement une représentation dans la syntaxe standard RDF/XML, ou indirectement en interprétant un autre dialecte en utilisant une transformation indiquée par le document. domain : InformationResource ; range : RDFGraph
• transformationProperty : relie une transformation à l'algorithme indiqué par la propriété calculant un graphe RDF d'après un nœud de documentXML. domain : Transformation ; range : TransformationProperty
• Transformation : une ressource d'information InformationResource qui définit une transformation depuis un ensemble de documents XML vers des graphes RDF. Chaque transformation Transformation a au moins un attribut transformationProperty qui est une propriété de transformation TransformationProperty
• TransformationProperty : une propriété fonctionnelle FunctionalProperty qui relie des nœuds racines de documents XML à des graphes RDF

Les termes suivants sont associés à des concepts de standards existants :

• RootNode : la racine de l'arbre dans le modèle de données XPath, selon la section 5.1 Le nœud racine, dans la spécification « Le langage XML Path (XPath version 1.0 »
• RDFGraph : un ensemble de triplets RDF, d'après la définition dans la spécification « Le cadre de description de ressources (RDF : Concepts et syntaxe abstraite »
• InformationResource : une ressource qui a pour propriété que toutes ses caractéristiques essentielles peuvent être véhiculées dans un message, d'après la définition dans la spécification « Architecture du World Wide Web, tome 1 »

Le document d'espace de noms inclut des données RDF à propos des termes du vocabulaire GRDDL, mais ces données RDF ne contiennent aucun triplet dont le prédicat est grddl:profileTransformation.

Dans la section « Utiliser GRDDL avec des documents d'espaces de noms XML », seuls les triplets explicites grddl:namespaceTransformation satisfont aux prémisses de la règle. De même, les triplets grddl:profileTransformation doivent être explicites dans le résultat GRDDL d'un document de profil pour satisfaire aux prémisses de la règle dans cette section et dans la section « GRDDL pour les profils HTML ». On conseille aux auteurs de documents sources GRDDL de ne pas utiliser d'expressions RDFS ou OWL qui impliquent de tels triplets mais ne les déclarent pas explicitement.

10. Références

Références normatives

RFC3987

Identificateurs de ressources internationalisés (IRI), Internet RFC 3987, janvier 2005. Duerst, Suignard

RFC3986

Identificateur de ressource uniforme (URI) : Syntaxe générique, Internet RFC 3986, janvier 2005. Berners-Lee, Fielding, Masinter

WEBARCH

Architecture du World Wide Web, tome 1, N. Walsh, I. Jacobs, rédacteurs, recommandation du W3C, 15 décembre 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . Dernière version disponible à http://www.w3.org/TR/webarch/ .

RDFC04

Le cadre de description de ressources (RDF) : Concepts et syntaxe abstraite, G. Klyne, J. J. Carroll, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Dernière version disponible à http://www.w3.org/TR/rdf-concepts/ .

RDF-MT

La sémantique RDF, P. Hayes, rédacteur, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Dernière version disponible à http://www.w3.org/TR/rdf-mt/ .

RDFX

La spécification de la syntaxe RDF/XML (révisée), D. Beckett, rédacteur, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . Dernière version disponible à http://www.w3.org/TR/rdf-syntax-grammar .

XMLBASE

XML Base, J. Marsh, rédacteur, recommandation du W3C, 27 juin 2001, http://www.w3.org/TR/2001/REC-xmlbase-20010627/ . Dernière version disponible à http://www.w3.org/TR/xmlbase/ .

XHTML

Modularisation de XHTML™, S. Schnitzenbaumer, F. Boumphrey, T. Wugofski, S. McCarron, M. Altheim, S. Dooley, rédacteurs, recommandation du W3C, 10 avril 2001, http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ . Dernière version disponible à http://www.w3.org/TR/xhtml-modularization/ .

HTML4

La spécification HTML 4.01, D. Raggett, A. Le Hors, I. Jacobs, rédacteurs, recommandation du W3C, 24 décembre 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . Dernière version disponible à http://www.w3.org/TR/html401 .

XPATH

Le langage de chemin XML (XPath) version 1.0, J. Clark, S. J. DeRose, rédacteurs, recommandation du W3C, 16 novembre 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 . Dernière version disponible à http://www.w3.org/TR/xpath .

XSLT1

Les transformations XSL (XSLT) version 1.0, J. Clark, rédacteur, recommandation du W3C, 16 novembre 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . Dernière version disponible à http://www.w3.org/TR/xslt .

Références informatives

Les documents suivants offre un éclairage supplémentaire mais ne font pas partie de cette spécification.

primer

Introduction à GRDDL, I. Davis, rédacteur, version de travail du W3C (en cours), 2 octobre 2006, http://www.w3.org/TR/2006/WD-grddl-primer-20061002/ . Dernière version disponible à http://www.w3.org/TR/grddl-primer/ .

usecases

Cas d'utilisation de GRDDL : Scénarios d'extraction de données RDF de documents XML, F. Gandon, Editor, note de groupe de travail du W3C, 6 avril 2007, http://www.w3.org/TR/2007/NOTE-grddl-scenarios-20070406/ . Dernière version disponible à http://www.w3.org/TR/grddl-scenarios/ .

GRDDL-TESTS

Jeux d'essais GRDDL, C. Ogbuji, rédacteur, recommandation du W3C, 11 septembre 2007, http://www.w3.org/TR/2007/REC-grddl-tests-20070911/ . Dernière version disponible à http://www.w3.org/TR/grddl-tests/ .

SPARQL

Le langage d'interrogation SPARQL pour RDF, E. Prud'hommeaux, A. Seaborne, rédacteurs, version de travail du W3C (en cours), 26 mars 2007, http://www.w3.org/TR/2007/WD-rdf-sparql-query-20070326/ . Dernière version disponible à http://www.w3.org/TR/rdf-sparql-query/ .

XSLT2

Les transformations XSL (XSLT) version 2.0, M. Kay, rédacteur, recommandation du W3C, 23 janvier 2007, http://www.w3.org/TR/2007/REC-xslt20-20070123/ . Dernière version disponible à http://www.w3.org/TR/xslt20 .

RFC2731

J. Kunze Le codage de métadonnées Dublin Core en HTML, 1999

XFN

XFN : Introduction et exemples, copyright GMPG 2003-2007. Eric, Tantek et Matt

DCRDF

Expression de métadonnées Simple Dublin Core en RDF/XML, Beckett, Miller, Brickley 2002-07-31

P3P

La spécification de la plateforme de préférences de confidentialité 1.0 (P3P1.0), M. Marchiori, rédacteur, recommandation du W3C, 16 avril 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . Dernière version disponible à http://www.w3.org/TR/P3P/ .

STYPI

Associer des feuilles de style aux documents XML, J. Clark, rédacteur, recommandation du W3C, 29 juin 1999, http://www.w3.org/1999/06/REC-xml-stylesheet-19990629 . Dernière version disponible à http://www.w3.org/TR/xml-stylesheet .

XPROC

XProc : Un langage de pipeline XML, N. Walsh, rédacteur, version de travail du W3C (en cours), 28 septembre 2006, http://www.w3.org/TR/2006/WD-xproc-20060928/ . Dernière version disponible à http://www.w3.org/TR/xproc/ .

MF-RDF-FAQ

La FAQ icroformat pour les fans de RDF, dernière modification 17:57, 30 mai 2006

Annexe : Transformations de style contre extraction de données (informatif)

L'instruction de traitement xml-stylesheet [STYPI] sert généralement pour un traitement de présentation automatique. Ce type de lien est différent des liens vers les algorithmes de transformation GRDDL, prévus pour faciliter l'extraction des données. Également, l'interprétation du contenu des instructions de traitement n'est pas gérée par les outils XML tels que les processeurs XSLT et l'ancrage des instructions de traitement dans l'espace URI n'est pas aussi facile que d'utiliser des espaces de noms avec les attributs.

Annexe : Réflexions autour de l'adresse IRI de base

Dans la sections « Ajouter du GRDDL à du XML bien formé », il est dit :

L'adresse IRI de base pour interpréter les références IRI relatives dans la sérialisation d'un graphe produit par une transformation GRDDL est l'adresse IRI de base du document source.

Cela concorde avec le document RFC 3986, notamment la section 5.1, qui illustre l'identification d'une adresse IRI de base par la figure suivante :

         .------------------------------------------------------------------.
         |  .------------------------------------------------------------.  |
         |  |  .------------------------------------------------------.  |  |
         |  |  |  .----------------------------------------.          |  |  |
         |  |  |  |  .----------------------------------.  |          |  |  |
         |  |  |  |  |       <relative-reference>       |  |          |  |  |
         |  |  |  |  `----------------------------------'  |          |  |  |
         |  |  |  | (5.1.1) Adresse URI de base incorporée |          |  |  |
         |  |  |  |              au contenu                |          |  |  |
         |  |  |  `----------------------------------------'          |  |  |
         |  |  | (5.1.2) Adresse URI de base de l'entité encapsulante |  |  |
         |  |  |           (message, représentation, ou rien)         |  |  |
         |  |  `------------------------------------------------------'  |  |
         |  | (5.1.3) Adresse URI utilisée pour récupérer l'entité       |  |
         |  `------------------------------------------------------------'  |
         | (5.1.4) Adresse URI de base par défaut (dépend de l'application) |
         `------------------------------------------------------------------'

Au cours d'un traitement GRDDL typique, une sérialisation RDF/XML intermédiaire est produite comme sortie d'une transformation. Pour convertir cette sérialisation en un graphe RDF, toutes les références relatives de la sérialisation sont résolues en adresses IRI. Pour identifier l'adresse IRI de base de résolution d'une référence relative, vérifiez d'abord s'il y a une adresse URI de base incorporée au sein du RDF/XML, conformément à XML Base, comme le permet la syntaxe RDF. Si aucune adresse URI de base n'est incorporée dans ce RDF/XML, alors la section 5.1.2 du document RFC 3986 peut s'appliquer, car l'entité encapsulante de cette sérialisation est l'élément racine du document en entrée. Si ce document ne définit pas d'adresse URI de base, alors son entité encapsulante, le document en entrée, peut définir une adresse IRI de base.

Le document original peut être un document de la famille XHTML, ou un autre document XML.

L'adresse IRI de base d'un document de la famille XHTML

Pour un document de la famille XHTML, l'adresse IRI de base du document en entrée peut être définie comme la valeur de l'attribut href de l'élément <base> (le cas échéant), conformément à la section 5.1.1 du document RFC 3986.

Dans beaucoup d'autres cas, la section 5.1.2 ne s'applique pas, c'est la section 5.1.3. La section 5.1.3 définit l'utilisation de l'adresse IRI de récupération comme étant l'adresse IRI de base. En outre, la section 5.1.3 du document RFC 3986 spécifie que :

Si la récupération est le résultat d'une requête redirigée, la dernière adresse URI utilisée (c'est-à-dire, l'adresse URI ayant abouti à la récupération réelle de la représentation) est l'adresse URI de base.

L'adresse IRI résultante est utilisée comme paramètre IRI de base pour le traitement de la sérialisation RDF/XML intermédiaire.

L'adresse IRI de base des autres documents XML

Les autres documents XML peuvent utiliser XML Base. Cela n'est recommandé que lorsque le format de document spécifique permet l'utilisation de XML Base.

Lorsqu'un attribut xml:base est présent sur l'élément racine d'un document XML, il définit l'adresse IRI de base pour ce document, conformément à la section 5.1.1 du document RFC 3986.

Lorsqu'il n'y a pas d'attribut xml:base sur l'élément racine, même s'il y en a un sur un élément descendant, la section 5.1.1 du document RFC 3986 ne s'applique pas.

Comme dans le cas XHTML, nous devons alors considérer les sections 5.1.2, 5.1.3 et 5.1.4 du document RFC 3986.

Parmi celles-ci, la section 5.1.3 représente le cas le plus courant et la remarque à propos d'une récupération redirigée s'applique aussi.

L'adresse IRI de base dans un pipeline de traitement

Un agent connaissant GRDDL calcule des résultats GRDDL lorsqu'il a :

l'adresse URI I d'une ressource d'information IR, et le nœud XPath N d'une représentation de IR

Pour utiliser un agent connaissant GRDDL dans un pipeline de traitement, ainsi que le nœud XPath N, il est également nécessaire d'indiquer une adresse IRI correspondante I. Elle sert d'adresse IRI de base lorsque les autres mécanismes ne s'appliquent pas. Cela concorde avec la section 5.1.4 du document RFC 3986. Il est même possible que l'adresse IRI utilisée par défaut n'ait aucune relation avec le nœud XPath N, mais dans ce cas nous lisons que :

Comme cette définition dépend forcément de l'application, ne pas définir d'adresse URI de base à l'aide d'une des autres méthodes peut aboutir à ce que le même contenu soit interprété différemment par des types d'applications différents.

L'émetteur d'une représentation contenant des références relatives a le devoir de s'assurer qu'une adresse URI de base puisse être établie pour ces références.

Les responsabilités du traitement correct des adresses IRI de base

Les auteurs de documents : en incluant des documents de profils et d'espaces de noms

Les auteurs de documents devraient en général inclure une adresse URI de base si le document est récupérable depuis une autre adresse URI.

Pour un document de la famille XHTML [XHTML], on utilise l'élément base.

Pour les autres documents XML, si le format gère l'attribut xml:base, il faudrait alors l'utiliser. En général, l'expérience suggère que les confusions sont moindres lorsqu'on le place sur l'élément racine. Les auteurs de document peuvent également utiliser des attributs xml:base ailleurs dans leurs documents, comme le permet le format de document, avec une sémantique définie par XML Base [XMLBASE].

Pour les documents XML dans des formats ne gérant pas l'attribut xml:base, et ne faisant pas partie de la famille XHTML, il n'existe aucun moyen dans GRDDL pour définir une adresse URI dans la ligne.

Si on peut accéder à un document de profil ou d'espace de noms via de multiples adresse URI, par exemple, par une redirection, les auteurs de documents devraient fournir, en général, un résultat GRDDL qui définit des transformations de profils ou d'espaces de noms pour chaque adresse URI.

Les agents connaissant GRDDL

Lorsqu'un résultat GRDDL est représenté en RDF/XML en utilisant la règle pour RDF/XML, une adresse URI de base sera peut-être nécessaire pour convertir cette représentation en un graphe RDF, conformément aux règles de la spécification de la syntaxe RDF/XML [RDFX].

Les résultats GRDDL représentés par d'autres moyens peuvent aussi avoir besoin d'une adresse URI de base.

En suivant l'analyse précédente, on définit l'adresse URI de base pour la résolution d'une référence relative conformément à la section 5.1 du document RFC 3986.

Dans beaucoup d'applications, il est très souhaitable que les résultats GRDDL dépendent de l'adresse URI par défaut de l'application, d'après la section 5.1.4 du document RFC 3986 ; certains agents connaissant GRDDL peuvent traiter cette possibilité comme une erreur.

Les auteurs de transformations GRDDL

En général, lorsqu'on écrit la transformation GRDDL d'un document de la famille XHTML vers RDF/XML, la meilleure solution est d'ignorer les problèmes liés à l'adresse URI de base. L'approche la plus facile est de produire des adresses URI relatives dans la sortie, correspondant aux adresses URI relatives dans l'entrée, et les adresses URI absolues correspondant aux concepts construits dans la transformation. Ces adresses URI relatives se résoudront, pendant le traitement effectué par l'agent connaissant GRDDL, par rapport à l'adresse URI de base correcte.

Lorsqu'on écrit la transformation d'un format de document XML qui ne gère pas xml:base, sans moyen de représenter une adresse URI de base dans la ligne, il n'y a pas d'autre choix que d'ignorer les questions de base correcte.

Lorsqu'on écrit la transformation GRDDL d'un format de document XML, autre qu'un document de la famille XHTML, qui ne gère pas xml:base, mais offrant un autre moyen de représenter une adresse URI de base dans la ligne, alors l'agent connaissant GRDDL ignorera ce moyen, et une transformation bien écrite essaiera de remédier à cela. Lorsqu'une adresse URI de base est définie de cette façon, une approche consiste à insérer l'adresse URI de base dans la sortie RDF/XML comme valeur d'un attribut xml:base, de sorte que l'interpréteur RDF/XML résolve les adresses URI relatives par rapport à cette base et ignore l'adresse URI de base passée par l'agent connaissant GRDDL, laquelle aura été calculée en ignorant les conventions spécifiques de ce format.

Lorsqu'on écrit la transformation GRDDL d'un format de document XML qui ne gère pas xml:base, il faut se souvenir que l'agent connaissant GRDDL est responsable de la manipulation de l'attribut xml:base sur l'élément racine. Si cet attribut xml:base existe, alors le comportement le plus simple pour une transformation GRDDL est de l'ignorer.

En revanche, les autres attributs xml:base, pas celui sur l'élément racine, sont de la responsabilité de la transformation, puisque l'agent connaissant GRDDL les ignore. Ces attributs xml:base des niveaux inférieurs devraient donc être honorés, le plus facile étant de les copier dans le graphe de sortie à l'endroit approprié. Quoiqu'il en soit, en général, les attributs xml:base des nœuds ancêtres doivent être également pris en compte, à moins qu'il n'y ait un attribut xml:base intermédiaire ayant pour valeur une adresse URI absolue. Ce n'est vraiment pas facile de bien faire : pour y parvenir, la bibliothèque GRDDL fournit un module à importer dans votre feuille de style, cf. ci-dessous.

Dans tous les cas, bien que ce soit souvent inutile, si une transformation a connaissance d'une adresse URI absolue, présente en entrée, pour le document entier, il n'est jamais incorrect de l'utiliser comme adresse URI de base pour la sortie, par exemple, en ajoutant un attribut xml:base approprié à l'élément rdf:RDF.

Les transformations qui le font doivent se garder d'appliquer un traitement similaire probablement incorrect aux adresses URI de base relatives. Par exemple, dans l'interaction entre un agent connaissant GRDDL correct et une transformation mal écrite, un attribut xml:base=".." sur l'élément racine pourrait s'appliquer deux fois, en donnant des références relatives résolues au mauvais niveau dans la hiérarchie des répertoires.