Lisez-moi S.V.P. 
W3C

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

Recommandation du W3C du 11 septembre 2007

Cette version :
http://www.w3.org/TR/2007/REC-grddl-20070911/
Dernière version :
http://www.w3.org/TR/grddl/
Version précédente :
http://www.w3.org/TR/2007/PR-grddl-20070716/
Rédacteur :
Dan Connolly
Auteurs :
Cf. la section Remerciements

Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections normatives.

Voir aussi les éventuelles traductions.


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

Documents associés :

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.

Des interprétations fidèles

En définissant une transformation GRDDL, l'auteur d'un document déclare que la transformation produira une interprétation fidèle en RDF des informations (ou d'une partie des informations) exprimées au travers du dialecte XML utilisé dans le document source.

De la même façon, en définissant une transformation d'espace de noms (ou de profil) GRDDL, le créateur de cet espace de noms (ou de ce profil) déclare que la transformation produira une interprétation RDF fidèle d'une classe de documents sources en rapport avec cet espace de noms (ou ce profil). Un document d'espace de noms (ou de profil) permet aussi à son auteur d'expliquer en prose le but de la transformation ou de laisser des instructions générales.

Préface et documents d'accompagnement

Cette spécification GRDDL est une définition technique concise du mécanisme GRDDL et de sa syntaxe XML. Elle définit la syntaxe GRDDL à utiliser dans les documents XHTML valides et XML bien formés, ainsi que la façon de coder du GRDDL dans les espaces de noms et les profils HTML. Les débats sur le lien de transformation GRDDL et les questions de sécurité sont égalements couverts. Les annexes fournissent des liens vers des exemples étendus et les logiciels et services existants utilisant GRDDL.

Introduction à GRDDL

L'introduction à GRDDL [primer] est un mode d'emploi pas-à-pas du mécanisme GRDDL. Il développe plusieurs exemples du document des cas d'utilisation GRDDL afin d'illustrer les techniques GRDDL d'association des documents aux transformations pour extraire le RDF.

Les cas d'utilisation GRDDL

Le document des cas d'utilisation [usecases] rassemble nombre de cas d'utilisation avec leurs objectifs et les préalables pour GRDDL. Ces cas d'utilisation montrent également comment on peut enrichir les documents XML et XHTML avec des microformats, du Embedded RDF et des déclarations RDFa pour soutenir les transformations GRDDL chargée de l'extraction des données de valeur qui peuvent alors être utilisées pour automatiser des tâches variées.

Les jeux d'essais GRDDL

Les jeux d'essais GRDDL [GRDDL-TESTS] fournissent un ensemble de tests illustrant cette spécification. Certains tests peuvent aider à clarifier la lecture attendue du texte normatif.

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.
Diagramme : lien vers plusieurs transformations

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.

Déclaration normativeRègle mécanique
(informatif)
Soit un nœud racine XPath [XPATH] N avec l'élément racine E, si l'expression
/*/@*[local-name()="transformation"
  and namespace-uri()=
    "http://www.w3.org/2003/g/data-view#"]
filtre un attribut d'un élément E, alors, pour chaque atome séparé par un espace REF dans la valeur de cet attribut, la ressource identifiée [WEBARCH] par la forme absolue (cf. section 5.2 Résolution relative, dans [RFC3986]) de REF par rapport à l'adresse IRI de base [RFC3987],[XMLBASE] de E est une transformation GRDDL de N.

Les atomes séparés par des espaces sont les sous-séquences maximales non vides ne contenant pas les caractères blancs #x9, #xA, #xD ou #x20.

(?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 :

Si une ressource d'information ([WEBARCH], section 2.2) IR est représentée par un document XML avec un nœud racine XPath R, que R a une transformation GRDDL avec une propriété de transformation TP, et que TP appliquée à R donne un graphe RDF [RDFC04] G, alors G est un résultat GRDDL de IR.
?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 :

Si F et G sont des résultats GRDDL de IR, alors la fusion [RDF-MT] de F et G est aussi un résultat GRDDL de IR.
?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 :

Diagramme : glaner via l'espace de noms
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 :

Déclaration normativeRègle mécanique
(informatif)
  • Si une ressource d'information NSDOC, identifiée par une adresse IRI NS a un résultat GRDDL incluant un triplet dont :
    • Le sujet est NSDOC, et
    • Le prédicat est la propriété <http://www.w3.org/2003/g/data-view#namespaceTransformation>, et
    • L'objet est TX
  • Et si une ressource d'information IR a une représentation XML avec un nœud racine NODE et avec un élément racine ayant pour nom d'espace de noms NS,
alors TX est une transformation GRDDL de NODE.
?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 :

Déclaration normativeRègle mécanique
(informatif)
Si une ressource d'information IR est représentée par un document RDF/XML conforme[RDFX], alors le graphe RDF représenté par ce document est un résultat GRDDL de IR.
?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 :

Diagramme : glaner via l'espace de noms

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 :

Diagramme : lien à la transformation

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" />
...
Diagramme : lien vers plusieurs transformations

Transformations multiples

(svg)

Règles GRDDL avec du XHTML valide

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

Soit le nœud racine XPath N, si N a pour nom de profil de métadonnées http://www.w3.org/2003/g/data-view, alors pour chaque élément descendant E d'un élément a ou link, dont l'attribut rel [HTML4] comporte l'atome transformation parmi ses valeurs séparées par des espaces, la ressource identifiée par la forme absolue de l'attribut href par rapport à l'adresse IRI de base de E est une transformation GRDDL de N.
?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.

Notez que l'adresse IRI de base d'un nœud d'élément dans un document XHTML peut être influencée par des facteurs tels que l'élément base [HTML4], l'adresse URI de récupération RFC3986, etc. Cf. l'annexe « Réflexions autour de l'adresse IRI de base, et les cas d'utilisation tel que htmlbase1 pour des éclaircissements.

La règle précédente dépend de la formalisation suivante des profils de métadonnées en XHTML :

Soit un nœud racine XPath N d'un document XHTML (c'est-à-dire un document XML dont l'élément racine a pour nom local html et pour nom d'espace de noms http://www.w3.org/1999/xhtml) pour chaque atome séparés par un espace REF dans la valeur de l'attribut profile [HTML4] de l'élément head E, la forme absolue de REF par rapport à l'adresse IRI de E est un nom de profil de métadonnées de N.
(?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.

Diagramme : transformation reliée indirectement via un profil

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 :

  • Si une ressource d'information PDOC, identifiée par une adresse IRI PNAME a un résultat GRDDL contenant un triplet dont :
    • Le sujet est PDOC, et
    • Le prédicat est la propriété <http://www.w3.org/2003/g/data-view#profileTransformation>, et
    • L'objet est TX,
  • Et si une ressource d'information IR a une représentation XML avec un nœud racine XPath NODE ayant pour nom de profil de métadonnées PNAME,
alors TX est une transformation GRDDL de NODE.
?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.

  • Si RDFXML est le nœud XPath racine d'un document RDF/XML conforme [RDFX] représentant un graphe RDF G,
  • Et si R est le nœud racine d'un certain document XML et TXNODE est le nœud racine d'une transformation XSLT [XSLT1],
  • Et si RDFXML est le nœud racine de l'arbre de résultat XSLT en application de TXNODE sur R,
  • Et si TXDOC est une ressource d'information avec une propriété de transformation TP représentée par un document XML ayant pour nœud racine TXNODE,
alors TP relie R à G.
?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.

À présent, lorsqu'une ressource d'information est représentée par un document XML, le modèle de données XPath correspondant peut ne pas être entièrement déterminé, par exemple, selon que l'agent élabore les inclusions, les entités paramètres, les attributs fixés ou implicites, ou vérifie des signatures numériques. Dit autrement, si un auteur assume la responsabilité des informations dans un document XML, quelles informations assume-t-il exactement ? Comment l'auteur peut-il garantir qu'une transformation satisfait à l'assurance d'interprétation fidèle GRDDL ?

Cette spécification est silencieuse sur la question de savoir quels processeurs XML employer par ou pour les agents connaissant GRDDL. Actuellement, ne sont pas définis si, oui ou non, ont lieu des traitements XInclude, de validité XML, de validité XML Schema, XML Signature ou XML Decryption. En revanche, la spécification anticipe que la résolution de la question TAG xmlFunctions-34 et la définition d'un modèle de traitement par défaut, par le groupe de travail XML Processing Model, fourniront des éclaircissements et une orientation, et les agents connaissant GRDDL sont censés s'y soumettre le moment venu. Que le processeur XSLT doive effectuer ces traitements avant d'exécuter une transformation GRDDL n'est pas l'opinion générale. Aussi, on suggère d'écrire les transformations GRDDL de telle sorte qu'elles puissent effectuer tous les prétraitements attendus, y compris le traitement des définitions DTD, des schémas et des espaces de noms associés. Ces mesures peuvent être évitées pour les documents ne nécessitant pas de tels prétraitements pour produire un ensemble d'information (N.d.T. infoset) qui soit fidèle. C'est-à-dire, pour les documents sans référence XInclude, définition DTD, XML Schema, et ainsi de suite.

Les auteurs de documents, en particulier ceux de documents XHTML, qu'ils souhaitent voir utilisés sans ambiguïté avec GRDDL, devraient éviter les dépendances envers un sous-ensemble DTD externe ; ils devraient notamment :

Un langage pour décrire les opérations à effectuer sur les documents XML (XProc : Un langage de pipeline XML [XPROC]) a récemment été publié comme version de travail du W3C. Il mérite qu'on s'y penche pour l'expression de transformations plus complexes ou sophistiquées nécessitant un contrôle du flux de traitement à travers des outils de traitement XML. Avec XProc, on pourrait appliquer une succession d'opérations à un document, tel une validation XInclude et une transformation, et abandonner le traitement, par exemple, si le résultat d'une étape intermédiaire n'était pas valide.

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.

Soit une ressource d'information IR, le nœud XPath N d'une représentation de IR, sous réserve des réflexions autour de la sécurité ci-dessous et de la politique locale exprimée dans sa configuration, un agent connaissant GRDDL devrait :

  1. Trouver chaque transformation associée à N, c'est-à-dire :
    1. chaque transformation associée à N via l'attribut grddl:transformation, comme dans la section « Ajouter du GRDDL à du XML bien formé » ;
    2. chaque transformation associée à N via des liens HTML (link) de type transformation, à condition que le document comporte un profil http://www.w3.org/2003/g/data-view , comme dans la section « Utiliser GRDDL avec du XHTML valide » ;
    3. chaque transformation indiquée par un document d'espace de noms disponible, comme dans la section « GRDDL pour les espaces de noms XML » ;
    4. chaque transformation indiquée par des profils XHTML, comme dans la section « GRDDL pour les profils HTML ».
  2. Appliquer sélectivement certaines ou toutes les transformations découvertes afin d'obtenir des résultats GRDDL. Notez que la sélection peut être guidée par les capacités de l'agent, les politiques de sécurité locales et éventuellement l'intervention de l'utilisateur/client ;
  3. Fusionner ces résultats GRDDL.

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.

Exemple : Le traçage de protocole d'un agent connaissant GRDDL

Bien que cette spécification déclarative de GRDDL autorise des stratégies de mise en œuvre diverses, nous traçons dans cet exemple, le comportement commun à beaucoup de mises en œuvre typiques.

Supposons un agent connaissant GRDDL auquel on demande des résultants depuis http://www.w3.org/2003/g/po-doc.xml. Il commence par résoudre cette adresse URI, et note que RDF/XML, HTML et XML sont des représentations acceptables :

[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>
...

Le document XML qui arrive n'a aucun balisage de transformation explicite mais les règles énoncées dans la section des espaces de noms XML suggèrent de consulter les résultats à partir du document d'espace de noms :

[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>
...

Nous n'avons pas encore de résultat dans la forme d'un document RDF/XML, mais cette fois nous trouvons un attribut transformation explicite dans l'espace de noms GRDDL, et nous suivons ce lien, en notant que les représentations XML sont acceptées :

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"
...

L'application de cette transformation produit :

<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>

Qui nous indique que .../grokPO.xsl est une transformation pour tous les documents dans l'espace de noms .../po-ex.

Continuant récursivement, nous examinons le document d'espace de noms à la recherche de po-ex.xsd. Comme il s'agit d'un document d'espace de noms bien connu, d'après la section « Réflexions autour de la sécurité », nous remarquons la date de dernière modification de notre copie en cache dans la requête, et le serveur origine nous fait savoir qu'elle est à jour :

[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

Puisque notre copie en cache du document d'espace de noms XML Schema ne comporte aucune transformation GRDDL associée, nous revenons à la transformation d'espace de noms depuis po-ex, c'est-à-dire à grokPO.xsl :

[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>
...

L'application de cette transformation à po-doc.xml produit du RDF/XML, nous l'interprétons en un graphe RDF (en utilisant l'adresse URI du document source, http://www.w3.org/2003/g/po-doc.xml, comme adresse URI de base), que nous retournons comme un résultat GRDDL de po-doc.xml :

<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>
...

Les données de traçage HTTP ont été collectées via le programme TCPWatch de Shane Hathaway. Pour plus de détails, cf. le traçage HTTP dans les documents de tests GRDDL.

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 :

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

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

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.

Remerciements et historique des changements

Un document d'accompagnement « Historique de la création de GRDDL et justification » discute cette création dans le contexte de HTML, PICS et RDF depuis environ 1997. Le rédacteur remercie chaleureusement les membres de la communauté pour leurs nombreuses contributions dans le développement de GRDDL :

Le groupe de travail GRDDL était convoqué en août 2006 avec Harry Halpin comme président et la participationd de plusieurs contributeurs et développeurs déjà cités, plus Chimezie Ogbuji, Fabien Gandon, Brian Suda et Rachel Yager.

Jeremy Carroll fournissait des réflexions détaillées sur la sécurité fondées sur le document RFC 2046 et mettait en place la liaison d'en-tête HTTP proposée par Ian Davis.

Le groupe de travail publiait la version du 24 octobre 2006. La liste des problèmes montre les décisions de conception majeures prises depuis.

Les seules modifications depuis la version du 16 juillet 2007, hormis la section de statut, sont les suivantes :