Gleaning Resource Descriptions from Dialects of Languages (GRDDL)

Abstract

GRDDL is a mechanism for Gleaning Resource Descriptions from Dialects of Languages. This GRDDL specification introduces markup based on existing standards for declaring that an XML document includes data compatible with the Resource Description Framework (RDF) and for linking to algorithms (typically represented in XSLT), for extracting this data from the document.

The markup includes a namespace-qualified attribute for use in general-purpose XML documents and a profile-qualified link relationship for use in valid XHTML documents. The GRDDL mechanism also allows an XML namespace document (or XHTML profile document) to declare that every document associated with that namespace (or profile) includes gleanable data and for linking to an algorithm for gleaning the data.

A corresponding GRDDL Use Case Working Draft provides motivating examples. A GRDDL Primer demonstrates the mechanism on XHTML documents which include widely-deployed dialects known as microformats.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This March 2007 release of the GRDDL specification is a Last Call Working Draft by the W3C GRDDL Working Group (part of the Semantic Web Activity) for review by W3C Members and other interested parties. The Working Group seeks confirmation that comments and issues have been addressed to the satisfaction of reviewers. Comments are due by 30 March 2007 to public-grddl-comments@w3.org, a mailing list with public archive). A log of changes is maintained for the convenience of editors and reviewers.

GRDDL is intended to contribute to addressing Web Architecture issues such as RDFinXHTML-35 and namespaceDocument-8 as well as issues postponed by the RDF Core working group such as rdfms-validating-embedded-rdf and faq-html-compliance.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction
2. Adding GRDDL to well-formed XML
3. GRDDL for XML Namespaces
4. Using GRDDL with valid XHTML
5. GRDDL for HTML Profiles
6. GRDDL Transformations
7. GRDDL-Aware Agents
8. Security Considerations
9. The GRDDL Vocabulary
10. References

• Appendix: Transformations for Styling versus data extraction
• Appendix: Issues
• Appendix: Acknowledgements and Change History

• Appendix: About the Mechanical Rules

1. Introduction: Data and Documents

There are many domain-specific languages ("dialects") used in practice among the many XML documents on the web. There are dialects of XHTML, XML and RDF that are used to represent everything from poetry to prose, purchase orders to invoices, spreadsheets to databases, schemas to scripts, and linked lists to ontologies.

While this breadth of expression is quite liberating, inspiring new dialects to represent information, it can be a barrier to understanding across different domains or fields. How, for example, does software discover the author of a poem, a spreadsheet and an ontology? And how can software determine whether authors of each are in fact the same?

The following are examples of how the same musical work might be described in different XML dialects:

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>

Although the examples above are obviously encodings of the same information, there remains no clear mechanism through which computer software might be able to determine this connection.

Resource Descriptions

The Resource Description Framework[RDFC04] provides a standard for making statements about resources in the form of a subject-predicate-object expression. One way to represent the fact "Are You Experienced?'s artist is The Jimi Hendrix Experience" in RDF would be as a triple whose subject is Are You Experienced, whose predicate is "has artist," and whose object is The Jimi Hendrix Experience. The predicate, "has artist" expresses a relationship between the subject (Are You Experienced?) and the object (The Jimi Hendrix Experience). Using URIs to uniquely identify the album, the artist and even the relationship would facilitate software design because not everyone knows The Jimi Hendrix Experience or even spells its name consistently.

Here's the information contained in the XML fragments above, this time expressed as 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>

Both the entities (subject and object resources) and relationships (predicates) are identified using unambiguous URIs.

Note that GRDDL follows HTML 4, RDF, and XML Schema in using Internationalized Resource Identifiers, i.e. IRIs[RFC3987]. While in informal usage, this specification uses the more familiar term URI interchangeably with the recently standardized term IRI, the formal rules use the relevant terms precisely.

The publishers of the XML above could also provide the same data in RDF using RDF/XML or one of the other RDF syntaxes. GRDDL provides a relatively inexpensive mechanism for bootstrapping RDF content from uniform XML dialects, shifting the burden from formulating RDF to creating transformation algorithms specifically for each dialect.

GRDDL works by associating transformations for an individual document, either through direct inclusion of references or indirectly through profile and namespace documents. Content authors can nominate the transformations for producing RDF from their content and use GRDDL to refer to them.

2. Adding GRDDL to well-formed XML

The general form of associating a GRDDL transformation link with a well-formed XML document is adding to the root element a grddl namespace declaration and a grddl:transformation attribute whose value is an IRI reference, or list of IRI references, that refer to executable scripts or programs which are expected to transform the source document into RDF. This method is suitable for use with any XML dialects that can accomodate an extra namespace-qualified attribute on the root element.

For example, this XML document is linked to two GRDDL transformations:

<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. It is linked to the transformation identified by http://www.w3.org/2001/sw/grddl-wg/td/getAuthor.xsl.
2. To resolve the relative URI reference glean_title.xsl to absolute form, we use the base URI of this XML element, which is http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.html in this example. Then this document is also linked to the GRDDL transformation identified by the absolute form, http://www.w3.org/2001/sw/grddl-wg/td/glean_title.xsl.

extracting title and author information

(svg)

As you will see in later sections, there are other ways to add GRDDL to HTML documents, especially designed to leverage HTML's existing capabilities and thereby overcome constraints imposed by the XML DTDs for some dialects of HTML. See Using GRDDL with valid XHTML and GRDDL for HTML Profiles.

The formal specification of this markup is given below. An informative mechanical version of each rule is given with the premise and the conclusion written as SPARQL graph patterns[SPARQL]. See the Mechanical Rules appendix for namespace prefix bindings and further explanation.

/*/@*[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.

The glean_title.xsl transformation computes the following RDF/XML document, given the XML document above as input:

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

The graph serialized by that document is a GRDDL result of the resource identified by http://www.w3.org/2001/sw/grddl-wg/td/titleauthor.html. Note that this serialization of the graph contains a relative URI reference (in the value of the rdf:about attribute). The base IRI for interpretting relative IRI references in a serialization of a graph produced by a GRDDL transformation is the IRI of the source document.

The glean_title.xsl resource specifies a function from XPath document nodes to RDF/XML documents, and hence to RDF graphs; this function is called the transformation property of the XSLT document. See the Transformation Algorithms section for more details.

The general rule for using GRDDL with well-formed XML is:

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

?IR grddl:result ?G .

The titleauthor.html resource has another GRDDL result via the getAuthor.xsl transformation. These results can be merged together into another result, by this rule:

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

?IR grddl:result ?H.

3. Using GRDDL with XML Namespace Documents

Transformations can be associated not only with individual documents but also with whole dialects that share an XML namespace. Any resource available for retrieval from a namespace URI is a namespace document (cf. section 4.5.4. Namespace documents in [WEBARCH]). For example, a namespace document may have an XML Schema representation or an RDF Schema representation, or perhaps both, using content negotiation.

To associate a GRDDL transformation with a whole dialect, have the namespace document include the grddl:namespaceTransformation property.

For example, consider this privacy policy written in P3Q, a contrived analog to P3P[P3P]:

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

The namespace document for P3Q relates the grokP3Q.xsl transformation to all P3Q documents:

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

That is: every document whose root namespace name is ...p3q-ns-example has grokP3Q.xsl as a GRDDL transformation implicitly, as illustrated in this figure:

transformation applied to namespace
(svg)

Some namespace documents, such as the XHTML namespace document http://www.w3.org/1999/xhtml have very many references to them. If GRDDL-aware agents were to retrieve these documents every time they processed a document referring to them, the origin servers of those documents could become overloaded. GRDDL-aware agents therefore should not retrieve such documents on every reference and should retain some cache or local memory of the transformations those documents indicate should be applied. To avoid misrepresentation of published information, GRDDL-aware agents should ensure that this local memory is up to date and should support user options to configure or disable the cache. See also section section 3.1. Using a URI to Access a Resource of [WEBARCH].

The general case of namespace transformations is:

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

Note that as a base case, the result of parsing an RDF/XML document is a GRDDL result of that document:

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

?IR grddl:result ?G.

Example: Using GRDDL with an XML Schema namespace document

A namespace transformation link may be discoverable by transforming the namespace document itself. Note that this means that namespace documents need not be written in RDF/XML directly.

Consider a purchase order that has a namespace document represented in XML Schema, where the XML Schema bears a data-view:transformation attribute licensing extraction of statements that include namespaceTransformation statements:

<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>This element is the root element.</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>
...

Every purchase order using that schema as a namespace document is linked to the grokPO.xsl transformation, as illustrated below:

using GRDDL with an XML Schema

(svg)

4. Using GRDDL with valid XHTML

To accomodate the DTD-based syntax of XHTML[XHTML], which precludes using attributes from foreign namespaces, we use http://www.w3.org/2003/g/data-view as a metadata profile (cf. section 7.4.4.3 Meta data profiles of [HTML4]).

The general form of adding a GRDDL assertion to a valid XHTML document is by specifying the GRDDL profile in the profile attribute of the head element, and transformation as the value of the rel attribute of a link or a element whose href attribute value is an IRI reference that refers to an executable script or program which is expected to transform the source document into RDF. This method is suitable for use with valid XHTML documents which are constrained by an XML DTD.

An example Dublin Core META transformation

For example, this document follows the conventions of [RFC2731], and it explicitly uses the GRDDL profile and links to an XSLT transformation that extracts the metadata in RDF/XML in a way that preserves the meaning of the document:

<html xmlns="http://www.w3.org/1999/xhtml">
  <head profile="http://www.w3.org/2003/g/data-view">
    <title>Some 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>

In the figure below, the arrow labelled info relates a document to an abstract notion of the information contained in the document. It shows that the RDF data extracted via the dc-extract.xsl transformation is part of the information contained in the document:

Decoding HTML meta-data to RDF

(svg)

This is what the data looks like in 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>

Multiple transformations in XHTML

An XHTML document may conform to a number of dialects simultaneously and link to more than one GRDDL transformation. However, since the href attribute of the link and a elements accept only a single IRI reference, multiple instances of these elements must be used to assert multiple links:

<!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>Joe Lambda's Home page [an example of RDF in 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" />
...

multiple transformations

(svg)

?N gspec:profileName "http://www.w3.org/2003/g/data-view".
(?N
""".//*[namespace-name()="http://www.w3.org/1999/xhtml" and
        (local-name() = "a"
         or local-name() = "link")"""
) gspec:xpath ?E.
(?E "@rel") gspec:xpath [ fn:string "transformation" ].
(?E "@href") gspec:xpath [ fn:string ?T_REF ].
?E fn:base-uri ?BASE.
(?T_REF ?BASE) fn:resolve-uri ?TURI.
?T log:uri ?TURI.

?N grddl:transformation ?T.

(?N
 """
*[local-name()="html" and
  namespace-name()="http://www.w3.org/1999/xhtml"] /
 *[local-name()="head" and
   namespace-name()="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 for HTML Profiles

XHTML provides the profile mechanism to link to the meaning of properties and the set of legal values for those properties. As with namespace documents, a profile document can effectively be written using XHTML with embedded RDF statements and a GRDDL transformation to extract the definition of terms that are applicable. Those terms can then be used in an XHTML document to convey profile-dependent meaning. As discussed in Using GRDDL with valid XHTML, the GRDDL profile can be used with XHTML documents to apply GRDDL semantics over link elements where the value of rel attribute is transformation. This very powerful and flexible mechanism integrates well with microformat profiles[MF-RDF-FAQ] which overlay the normally semantically-poor HTML markup.

The following diagram illustrates an XFN document, friends.html associated with the grokXFN.xsl transformation indirectly via an XFN profile.

indirection via profile

(svg)

Adding a GRDDL profileTransformation assertion to a profile document is much like adding a namespaceTransformation assertion to a namespace document. For a dialect defined by a valid XHTML profile documents, add profile="http://www.w3.org/2003/g/data-view" to the head element and make a link of type profileTransformation to the transformation of the dialect.

The general rule is:

?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. Transformation Algorithms

As noted above, each GRDDL transformation specifies a transformation property, a function from XPath document nodes to RDF/XML documents, and hence to RDF graphs. This function need not be total; it may have a domain smaller than all XML document nodes. For example, use of xsl:message with terminate="yes" may be used to signal that the input is outside the domain of the transformation.

Developers of transformations should make available representations in widely-supported formats. XSLT version 1[XSLT1] is the format most widely supported by GRDDL-aware agents as of this writing, though though XSLT2[XSLT2] deployment is increasing. While technically Javascript, C, or virtually any other programming language may be used to express transformations for GRDDL, XSLT is specifically designed to express XML to XML transformations and has some good safety characteristics.

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

?R ?TP ?G

When an information resource is represented by an XML document, the corresponding XPath data model may not be fully determined, depending on, for example, whether an agent elaborates inclusions, parameter entities, fixed and default attributes, or checks digital signatures. Put another way, if an author takes responsibility for the information in an XML document, for what information exactly is the author taking responsibility? And how can the author ensure that a GRDDL transformation is able to meet GRDDL's Faithful Rendition assurance?

This specification is purposely silent on the question of which XML processors are employed by or for GRDDL-aware agents. Whether or not processing of XInclude, XML Validity, XML Schema Validity, XML Signatures or XML Decryption take place is implementation-defined. There is no universal expectation that an XSLT processor will call on such processing before executing a GRDDL transformation. Therefore, it is suggested that GRDDL transformations be written so that they perform all expected pre-processing, including processing of related DTDs, Schemas and namespaces. Such measure can be avoided for documents which do not require such pre-processing to yield an infoset that is faithful. That is, for documents which do not reference XInclude, DTDs, XML Schemas and so on.

XProc: An XML Pipeline Language[XPROC], a language for describing operations to be performed on XML documents, has recently been published as a W3C Working Draft. It merits consideration for expressing more complex or sophisticated transformations which require control over the flow of processing through a variety of XML processing tools. Using XProc, one could apply a sequence of operations such XInclude, validation, and transformation to a document, aborting if the result of an intermediate stage is not valid, for example.

7. GRDDL-Aware Agents

A GRDDL-aware agent is a software module that computes GRDDL results of information resources.

For example, a SPARQL query service might use a GRDDL-aware agent for collecting RDF data. Or a Web browser might serve as a GRDDL-aware agent for the purpose of collecting calendar and contact data. The appropriate policy, for which results to compute and when, is likely to involve waiting for a signal from user more in the Web browser case than in the query service case.

Note that discovery by namespace or profile document is recursive; Loops in the profile/namespace structure should be detected in order to avoid infinite recursion.

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

The execution of general-purpose programming languages as interpreters for transformations exposes serious security risks. Designers of GRDDL-aware agents are advised to guard against simply sending GRDDL transformations to "off-the-shelf" interpreters. While it is usually safe to pass documents from trusted sources through a GRDDL transformation, implementors should consider all of the following before adding the ability to execute arbitrary GRDDL transformations linked from arbitrary Web documents.

GRDDL, like many Web technologies, fundamentally relies on the dereferencing of URIs. Writers of GRDDL transformations are advised against employing URL operations which are potentially dangerous, because these operations are more likely to be unavailable in secure GRDDL implementations. Software executing GRDDL transformations are advised to either completely disable all potentially dangerous URL operations or take special care not to delegate any special authority to their operation. In particular, operations to read or write URLs are more safely executed with the privileges associated with an untrusted party, rather than the current user. Such disabling and/or checking should be done completely outside of the reach of the transformation language itself; care should be taken to insure that no method exists for re-enabling full-function versions of these operators.

The remainder of this section outlines some, though probably not all, of the possible problems with the execution of GRDDL transformations, with particular reference to transformations in XSLT.

1. With unconstrained use of GRDDL, untrusted transformations may access URLs which the end-user has read or write permission, while the author of the transformation does not. This is particularly pertinent for URLs from the file: scheme; but many other schemes are also impacted. The untrusted code may, having read documents which the author did not have permission to access, transmit the content of the documents, to arbitrary Web servers by encoding the contents within a URL, that may be passed to the server.
2. Dangerous operations in the XSLT language include, but may not be limited to, the operations involving getting a URL: document(), doc(), unparsed-text() and unparsed-text-available(), and xsl:result-document which involves writing to a URL. xsl:include and xsl:import present fewer risks if they are processed before execution of the transformation, rather than during it.
3. Some transformation language implementations may provide facilities for loading and executing other programming language code. For example, an XSLT implementation may provide a method for executing Java code. Such facilities are obviously open to abuse. Designers of GRDDL transformations are advised against making use of such features. Besides being implementation-specific, they are more likely to be unavailable in secure implementations of the transformation language. The use of such operators in software executing GRDDL transformations should protect against such operators in case they are encountered.
4. XSLT implementations often provide their own extensions. Designers of GRDDL transformations are advised not make use of extensions because they are not guaranteed to be present in all implementations. Software executing GRDDL transformations should make sure that extensions are secure and do not present any kind of threat.
5. Since it is possible to write transformations that inordinately consume system resources or that loop indefinitely. Both types of transformations have the potential to cause damage if sent to unsuspecting recipients. Designers of GRDDL transformations are advised to avoid the construction and dissemination of such transformations. Software executing GRDDL transformations should provide appropriate mechanisms to abort processing after a reasonable amount of time has elapsed. In addition, GRDDL software should be limited to the consumption of only a reasonable amount of any given system resource.
6. Finally, bugs may exist in some interpreters of a transformation language which might be exploited to gain unauthorized access to a recipient's system. Apart from noting this possibility, no specific action is advised to take to prevent this aside from timely correction of such bugs as they are discovered.

9. The GRDDL Vocabulary

The following is excerpted from the GRDDL profile/namespace document:

This document, http://www.w3.org/2003/g/data-view, is a metadata profile in the sense of the HTML specification, in section 7.4.4.3 Meta data profiles.

The following term is introduced here as an XHTML link relationship name and RDF property name:

• transformation: relates a source document to a transformation, usually represented in XSLT, that relates the source document syntax to the RDF graph syntax. domain: RootNode; range: Transformation

The following terms are introduced here as RDF properties:

• namespaceTransformation: relates a namespace to a transformation for all documents in that namespace. range: Transformation
• profileTransformation: relates a profile document to a transformation for all documents bearing that profile. range: Transformation
• result: an RDF graph obtained from an information resource by directly parsing a representation in the standard RDF/XML syntax or indirectly by parsing some other dialect using a transformation nominated by the document. domain: InformationResource; range: RDFGraph
• transformationProperty relates a transformation to the algorithm specified by the property that computes an RDF graph from an XML document node domain: Transformation range: TransformationProperty

The following terms are bound to concepts from existing standards:

• RootNode the root of the tree in the XPath data model, per section 5.1 Root Node in XML Path Language (XPath) Version 1.0
• RDFGraph a set of RDF triples, per definition in Resource Description Framework (RDF): Concepts and Abstract Syntax
• InformationResource A resource which has the property that all of its essential characteristics can be conveyed in a message, per definition in Architecture of the World Wide Web, Volume One
• Transformation an InformationResource that specifies a transformation from a set of XML documents to RDF graphs Each Transformation has at least one transformationProperty that is a TransformationProperty.
• TransformationProperty a Property that relates XML document root nodes to RDF graphs

The namespace document includes RDF data about the terms in the GRDDL Vocuabulary, but these RDF data do not include any triples whose predicate is grddl:profileTransformation.

10. References

Normative References

RFC3987

Internationalized Resource Identifiers (IRIs) Internet RFC 3987 January 2005. Duerst, Suignard

RFC3986

Uniform Resource Identifier (URI): Generic Syntax Internet RFC3986 January 2005. Berners-Lee, Fielding, Masinter

WEBARCH

Architecture of the World Wide Web, Volume One , N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/ . Latest version available at http://www.w3.org/TR/webarch/ .

RDFC04

Resource Description Framework (RDF): Concepts and Abstract Syntax , G. Klyne, J. J. Carroll, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ . Latest version available at http://www.w3.org/TR/rdf-concepts/ .

RDF-MT

RDF Semantics , P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ . Latest version available at http://www.w3.org/TR/rdf-mt/ .

RDFX

RDF/XML Syntax Specification (Revised), D. Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ . Latest version available at http://www.w3.org/TR/rdf-syntax-grammar .

XHTML

Modularization of XHTML™ , S. Schnitzenbaumer, F. Boumphrey, T. Wugofski, S. McCarron, M. Altheim, S. Dooley, Editors, W3C Recommendation, 10 April 2001, http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/ . Latest version available at http://www.w3.org/TR/xhtml-modularization/ .

HTML4

HTML 4.01 Specification , D. Raggett, A. Le Hors, I. Jacobs, Editors, W3C Recommendation, 24 December 1999, http://www.w3.org/TR/1999/REC-html401-19991224 . Latest version available at http://www.w3.org/TR/html401 .

XPATH

XML Path Language (XPath) Version 1.0 , J. Clark, S. J. DeRose, Editors, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xpath-19991116 . Latest version available at http://www.w3.org/TR/xpath .

XSLT1

XSL Transformations (XSLT) Version 1.0 , J. Clark, Editor, W3C Recommendation, 16 November 1999, http://www.w3.org/TR/1999/REC-xslt-19991116 . Latest version available at http://www.w3.org/TR/xslt .

Informative references

The following documents provide additional background but are not part of this specification.

primer

GRDDL Primer , I. Davis, Editor, W3C Working Draft (work in progress), 2 October 2006, http://www.w3.org/TR/2006/WD-grddl-primer-20061002/ . Latest version available at http://www.w3.org/TR/grddl-primer/ .

usecases

GRDDL Use Cases: Scenarios of extracting RDF data from XML documents , F. Gandon, Editor, W3C Working Draft (work in progress), 2 October 2006, http://www.w3.org/TR/2006/WD-grddl-scenarios-20061002/ . Latest version available at http://www.w3.org/TR/grddl-scenarios/ .

SPARQL

SPARQL Query Language for RDF , A. Seaborne, E. Prud'hommeaux, Editors, W3C Working Draft (work in progress), 4 October 2006, http://www.w3.org/TR/2006/WD-rdf-sparql-query-20061004/ . Latest version available at http://www.w3.org/TR/rdf-sparql-query/ .

XSLT2

XSL Transformations (XSLT) Version 2.0 , M. Kay, Editor, W3C Working Draft (work in progress), 11 February 2005, http://www.w3.org/TR/2005/WD-xslt20-20050211/ . Latest version available at http://www.w3.org/TR/xslt20 .

RFC2731

J. Kunze Encoding Dublin Core Metadata in HTML in 1999

DCRDF

Expressing Simple Dublin Core in RDF/XML Beckett, Miller, Brickley 2002-07-31

P3P

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification , M. Marchiori, Editor, W3C Recommendation, 16 April 2002, http://www.w3.org/TR/2002/REC-P3P-20020416/ . Latest version available at http://www.w3.org/TR/P3P/ .

STYPI

Associating Style Sheets with XML documents , J. Clark, Editor, W3C Recommendation, 29 June 1999, http://www.w3.org/1999/06/REC-xml-stylesheet-19990629 . Latest version available at http://www.w3.org/TR/xml-stylesheet .

XPROC

XProc: An XML Pipeline Language , N. Walsh, Editor, W3C Working Draft (work in progress), 28 September 2006, http://www.w3.org/TR/2006/WD-xproc-20060928/ . Latest version available at http://www.w3.org/TR/xproc/ .

MF-RDF-FAQ

Microformat FAQs for RDF Fans, last modified 17:57, 30 May 2006

Appendix: Transformations for Styling versus data extraction

The xml-stylesheet processing instruction[STYPI] is generally deployed for automated presentation processing. This type of link is different from links to GRDDL transformation algorithms, which are intended to facilitate extracting data. Also, parsing the content of processing instructions is not supported by XML tools such as XSLT processors, and grounding processing instructions in URI space is not as straightforward as using namespaces with attributes.

Appendix: Issues

The following issues have been resolved by the Working Group:

• issue-whichlangs: which languages, if any, should GRDDL clients/processors be required to support? XSLT1? XSLT2? ECMAscript? closed 2006-08-30
• issue-output-formats: whether GRDDL transformations may produce RDF in a format other than RDF/XML. closed in 2006-12-06 discussion

  discussed in the March 2006 SemWeb IG meeting; see irc notes

  See also GRDDL extraction *to* RDFa Ben Adida (Friday, 8 September) and following, and comments on Sequential Transformations 20 Oct

  See testlist1#atomttl1, i.e. "you may support turtle"

• issue-base-param: how the transformation algorithm gets the base URI. closed in 2006-12-20 discussion
• issue-tx-element: is there a way to push the grddl:transformation attribute down from the document element to individual elements without breaking the chain of authority?

  POSTPONED 2007-01-17

  See RDF in parts of XHTML documents 09 Mar 2004 and discussion of trackback in an 18 March message.

• issue-html-nsdoc: what caching policy should GRDDL-aware agents adopt for the XHTML namespace document?

  Several early ones have a "never fetch it; there are no GRDDL transformations there, so don't even look" policy.

  See also #swig discussion 2006-12-28

  CLOSED in 2007-01-24 discussion

• faithful-infoset: what infoset to use as the input to GRDDL transformations? do XInclude?

  closed in 2007-01-31 discussion

  was split out from issue-mt-ns and closed in 2006-12-20 discussion; re-opened 10 Jan. See also: Testing Xinclude GRDDL Tests, Part 3 (which might move to part 1)

• issue-mt-ns: how GRDDL interacts with XML and RDF media types

  closed in 2007-02-07 discussion the current rules address issue-mt-ns; in particular, the RDF/XML base case rule in the namespaces section

  including:

  • how a GRDDL client interacts with a document whose root element is an XSLT literal result element (note jjc 7 Dec)
  • how a GRDDL client interacts with an RDF document that has a root element other than rdf:RDF. see Grddl Squirrel 6 test cases, McBride, 9 Mar 2006
  • whether RDF/XML statements labelled as application/xml constitute a "document whose meaning includes the RDF statement ..." (9 Mar 2006 from McBride)
  • what happens if data-view:transformation is given on an rdf:RDF root element (9 Mar 2006 from McBride)
• issue-conformance-labels: which conformance labels, if any, should we have?

  reconsidered 14 Feb in light of comment on security considerations from Carroll 13 Feb and closed in 2007-02-21 discussion: RESOLVED: to include "GRDDL-aware agent" as a conformance-label ...

  previously, closed 2007-01-17: use consistent vocabulary, but not use them as conformance labels; re-considered 14 Feb in light of comment on security considerations 13 Feb from Carroll

• issue-http-header-links: should links expressed in HTTP headers be supported?

  initially closed in 2007-02-07 discussion; after consideration of use case, RESOLVED: to add the GRDDL header to the GRDDL spec, per IanD's proposal contingent on IETF registration of Profile header, and on succesful test experience

  reconsidered in light of Connolly 21 Feb and postponed in 28 Feb discussion: postpone the issue, since a URI-based linking feature in HTTP such as the Profile header field is not yet stable/ratified/standardized

  • mnot's draft (expired; ISOC latest version)
  • RFC2068, containing the BCP Link spec, cited from
  • 2.1.62. Header field: Link of HTTP Header Field Registrations RFC4229 December 2005, which is the reference for Link in the...
  • permanent header registry, which was established by IETF consensus recorded in Registration Procedures for Message Header Fields September 2004

  see also test experience report by jjc 7 Feb

  raised by Connolly 11Sep; sketch 31 Jan by Ian Davis