Copyright © 2006-2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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. A GRDDL Test Cases document illustrates specific issues in this design and provides materials to aid in test-driven development of GRDDL-aware agents.
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 2nd May 2007 release of the GRDDL Specification is a Candidate Recommendation; it been widely reviewed and satisfies the requirements documented in GRDDL Charter; W3C publishes a Candidate Recommendation to gather implementation experience. A log of changes is maintained for the convenience of editors and reviewers. Normative assertions are marked up in this way.
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.
The first release of this document as a Working Draft was 24 Oct 2006 and the GRDDL Working Group has made its best effort to address comments received since then, and has also resolved all outstanding issues list of issues meanwhile. There are no normative dependencies to this document that would prevent it from being advanced to Proposed Recommendation status. The design has stabilized and the Working Group intends to advance this specification to Proposed Recommendation once the exit criteria below are met:
This specification will remain a Candidate Recommendation until at least 30 May 2007.
Comments on this document should be sent to [email protected], a mailing list with a public archive.
Publication as a Candidate Recommendation 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.
A draft GRDDL Test Cases are available, upon which an in progress implementation report is based.
W3C provides pair of online services on an experimental, best-effort basis:
The GrddlImplementations topic in the ESW Wiki is a community-maintained lists of GRDDL implementations in C, Java, Python, PHP and perhaps other languages.
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:
<key>Artist</key> <string>The Jimi Hendrix Experience</string> <key>Album</key> <string>Are You Experienced?</string>
<album> <artist mbid="">The Jimi Hendrix Experience</artist> <name>Are You Experienced?</name> ... </album>
<entry ... > <title>Are You Experienced?</title> <author> <name>The Jimi Hendrix Experience</name> </author> ... </entry>
<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.
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.
By specifying a GRDDL transformation, the author of a document states that the transformation will provide a faithful rendition in RDF of information (or some portion of the information) expressed through the XML dialect used in the source document.
Likewise, by specifying a GRDDL namespace transformation or profile transformation, the creator of that namespace or profile states that the transformation will provide a faithful RDF rendition of a class of source documents which relate to that namespace or profile. A namespace document or a profile document also provide a means for their authors to explain in prose the purpose of the transformation or any policy statements.
This GRDDL specification is a concise technical specification of the GRDDL mechanism and its XML syntax. It specifies the GRDDL syntax to use in valid XHTML and well-formed XML documents, as well as how to encode GRDDL into namespaces and HTML profiles. Discussions of the GRDDL transformation link and security issues are also covered. Appendices provide links to extended examples and existing software and services that employ GRDDL.
The GRDDL Primer[primer] is a step-by-step tutorial on the GRDDL mechanism. It develops a number of examples from the GRDDL Use Cases document to illustrate GRDDL techniques for associating documents with transformations for extracting RDF.
The use cases document[usecases] collects a number of use cases with their goals and requirements for GRDDL. These use cases also illustrate how XML and XHTML documents can be decorated with microformats, Embedded RDF or RDFa statements to support GRDDL transformations in charge of extracting valuable data that can then be used to automate a variety of tasks.
The GRDDL Test Cases[GRDDL-TESTS] provides a collection of tests illustrating this specification. Some of the tests may help clarify the intended reading of the normative text.
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>
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. These are included for those readers who find them helpful. Other readers are encouraged to ignore them.
Normative Statement | Mechanical Rule (Informative) |
|||
---|---|---|---|---|
Given an XPath[XPATH] root
node N with root element E,
if the expression
/*/@*[local-name()="transformation" and namespace-uri()= "http://www.w3.org/2003/g/data-view#"]matches an attribute of an element E, then for each space-separated token REF in the value of that attribute, the resource identified[WEBARCH] by the absolute form (see section 5.2 Relative Resolution in [RFC3986]) of REF with respect to the base IRI[RFC3987],[XMLBASE] of E is a GRDDL transformation of N. Space-separated tokens are the maximal non-empty subsequences not containing the whitespace characters #x9, #xA, #xD or #x20. |
|
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 GRDDL Transformations section for more details.
The general rule for using GRDDL with well-formed XML is:
If an information resource([WEBARCH], section 2.2) IR is represented by an XML document with an XPath root node R, and R has a GRDDL transformation with a transformation property TP, and TP applied to R gives an RDF Graph[RDFC04] G, then G is a GRDDL result of IR. |
|
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:
If F and G are GRDDL results of IR, then the merge [RDF-MT] of F and G is also a GRDDL result of IR. |
|
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, include
a grddl:namespaceTransformation
property in a GRDDL
result of the namespace document.
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:
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:
Normative Statement | Mechanical Rule (Informative) |
|||
---|---|---|---|---|
If
|
|
Note that as a base case, the result of parsing an RDF/XML document is a GRDDL result of that document:
Normative Statement | Mechanical Rule (Informative) |
|||
---|---|---|---|---|
If an information resource IR is represented by a conforming RDF/XML document[RDFX], then the RDF graph represented by that document is a GRDDL result of IR. |
|
Note that while an application/rdf+xml media type is one
indication that a document is RDF/XML, section 7.2.1 Grammar start of [RDFX] leaves open
"other means" by which an RDF/XML document may be identified. For the
purposes of the rule above, a root element whose local name is
RDF
and whose namespace URI is
http://www.w3.org/1999/02/22-rdf-syntax-ns#
is such a
means. For a case in point, see the grddlonrdf-xmlmediatype test case.
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)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.
For example, this document follows the conventions of [RFC2731], and it explicitly uses the GRDDL profile and links to an XSLT transformation to in RDF/XML to signal that the transformation is a faithful rendition:
<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>
The figure below shows the source document, the dc-extract.xsl transformation, and the GRDDL result:
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>
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)The general rule is:
Given XPath root node N, if N has metadata profile name http://www.w3.org/2003/g/data-view, then for each a and link descendant element E whose rel attribute[HTML4] has transformation as one of its space separated values the resource identified by the absolute form of the href attribute with respect to the base IRI of E is a GRDDL transformation of N. |
|
Note that the base IRI of an element node in an XHTML document may be influenced by factors such as a base element[HTML4] Retrieval URIRFC3986, etc. See test cases such as htmlbase1 for further clarification.
The rule above depends on the following formalization of metadata profiles in XHTML:
Given an XPath root node N of an XHTML document (that is, an XML document whose root element has a local name of html and a namespace name of http://www.w3.org/1999/xhtml) for each space-separated token REF in the value of the profile attribute[HTML4] of the head element E, the absolute form of REF with respect to the base IRI of E is a metadata profile name of N. |
|
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[XFN], 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:
If
|
|
As noted above, each GRDDL transformation specifies a transformation property, a function from XPath document nodes 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.
If
|
|
The rule above covers the case of a transformation property that relates an XPath document node to an RDF graph via an RDF/XML document. Transformations may use other, unspecified, mechanisms. For example, see test #atomttl1, in which the the media-type attribute of the xsl:output element bears a "text/rdf+n3" value to indicate a media type other than "application/rdf+xml". GRDDL agents that can process such a media type can then produce an RDF graph in accordance with the media type. Non-XSLT transforms may indicate the RDF graph in some other, unspecified, fashion.
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.
Document authors, particularly XHTML document authors, who wish their documents to be unambiguous when used with GRDDL should avoid dependencies on an external DTD subset (see section 2.8 of [XML]); specifically:
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.
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.
Subject to security considerations below and local policy as expressed in its configuration, given a URI I of an information resource IR, and an XPath node N for a representation of IR, a GRDDL-aware agent should:
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.
While this declarative specification of GRDDL allows a variety of implementation strategies, in this example we trace the behavior common to a number of typical implementations.
Consider a GRDDL-aware agent that is asked for results from http://www.w3.org/2003/g/po-doc.xml. It starts by dereferencing that URI, noting that RDF/XML, HTML, and XML are acceptable representations:
[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> ...
The XML document that comes back has no explicit transformation markup, but the rules in the XML Namespaces section suggest looking up results from the namespace document:
[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> ...
We don't yet have a result in the form of an RDF/XML document, but this time we find an explicit transformation attribute in the GRDDL namespace, so we follow that link, noting that we accept XML representations:
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" ...
Applying that transformation yields...
<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>
... which tells us that .../grokPO.xsl is a transformation for all documents in the .../po-ex namespace.
Continuing recursively, we examine the namespace document for po-ex.xsd. As this is a well-known namespace document, following the Security considerations section, we note the last modified date of our cached copy in the request, and the origin server lets us know that our copy is current:
[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
Since our cached copy of the XML Schema namespace document shows no associated GRDDL transformation, we return to the namespace transformation from po-ex, i.e. 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> ...
Applying this transformation to po-doc.xml yields RDF/XML; we parse this to an RDF graph (using the URI of the source document, http://www.w3.org/2003/g/po-doc.xml, as the base URI) and return the graph as a GRDDL result of 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> ...
HTTP trace data was collected via TCPWatch by Shane Hathaway. For more details, see HTTP tracing in the GRDDL test materials.
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.
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
- 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 FunctionalProperty that relates XML document root nodes to RDF graphs
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
The namespace document includes RDF data about the terms in the GRDDL Vocabulary, but these RDF data do not include any triples whose predicate is grddl:profileTransformation.
In the section on Using GRDDL with XML Namespace Documents, only explicit grddl:namespaceTransformation triples satisfy the premise of the rule. Likewise, grddl:profileTransformation triples must be explicit in the GRDDL result of a profile document in order to satisfy the premise of the rule in the section on and on GRDDL for HTML Profiles. Authors of GRDDL source documents are advised against using RDFS or OWL expressions which imply such triples but do not explicitly state them.
The following documents provide additional background but are not part of this specification.
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.
The following issues have been resolved by the Working Group:
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"
POSTPONED 2007-01-17
See RDF in parts of XHTML documents 09 Mar 2004 and discussion of trackback in an 18 March message.
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
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)
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:
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
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
see also test experience report by jjc 7 Feb
raised by Connolly 11Sep; sketch 31 Jan by Ian Davis
A companion GRDDL design history and rationale discusses this design in the context of HTML, PICS, and RDF since about 1997. The editor greatfully acknowledges the many contributions of community members in the development of GRDDL:
The suggested way of including RDF meta data in HTML is not compliant with HTML 4.01 or XHTML; in Apr 2001, Lee Jonas raised issue rdfms-validating-embedded-rdf:
RDF embedded in XHTML and other XML documents is hard to validate.
The GRDDL Working Group convened August 2006 with Harry Halpin as chair and several of the contributors and implementors above participating, plus Chimezie Ogbuji, Fabien Gandon, Brian Suda, and Rachel Yager.
Jeremy Carroll provided detailed security considerations based on RFC 2046 and implemented the HTTP header linking as proposed by Ian Davis.
The Working Group published a 24 October 2006 draft. The issues list above shows the major design decisions since then.
Changes since the 2 March 2007 release are as follows:
$Log: Overview.html,v $ Revision 1.7 2018/10/09 13:17:23 denis fix validation of xhtml documents Revision 1.6 2017/10/02 10:33:06 denis add fixup.js to old specs Revision 1.5 2007/05/03 14:17:51 connolly added XML citation fixed XSLT2, RFC3987 citation links Revision 1.4 2007/05/02 14:29:49 connolly "This section..." boilerplate, one more time Revision 1.3 2007/05/02 14:28:22 connolly remove PUBFIX Revision 1.2 2007/05/02 14:27:29 connolly update title page from editor's draft to CR Revision 1.1 2007/05/02 14:23:42 connolly snapshot of editor draft Revision 1.260 2007/05/02 14:16:14 connolly incorporate status section from CR request Revision 1.259 2007/05/02 13:44:48 connolly - Fixed some text in the Transformations section to match the rules: the output of a GRDDL transformation is an RDF graph, not an RDF/XML document. -- edited #txforms section labels for consistency - updated the GRDDL namespace document excerpt to formalize the fact that GRDDL Transformations are FunctionalProperties -- moved the parts that weren't a quote outside the quote Revision 1.258 2007/04/30 15:19:30 connolly update usecases cite Revision 1.257 2007/04/26 23:03:29 connolly - in response to Beckett 4 Apr: -- noted in SOTD that normative assertions are marked up distinctively, to clarify that the long example is informative. Marked "Styling versus..." appendix as informative -- rephrased confusing sentence about associating a GRDDL transformation with a whole dialect -- fixed spelling of Vocabulary - trimmed changelog Revision 1.256 2007/04/26 22:48:53 connolly cite XFN informatively update citations for XSLT2, SPARQL Revision 1.255 2007/04/26 15:47:24 connolly - per 24 Apr minutes: -- RESOLVED: that the premise of the rel="transform" rule depend only on (a) XML-wf-ness (b) root element name "html", (c) root element namespace http://www.w3.org/1999/xhtml -- ACTION: DanC to yes, cite htmlbase1 to clarify "base IRI of E" in the case of XHTML --- replaced fn:base-uri with gspec:htmlBase in mechanical rules [untested] -- ACTION: DanC to add test cases to spec abstract -- ACTION: DanC to demote test citation to informative -- ACTION: DanC to s/metdata/metadata/ - use namespace-uri() XPath function in mechanical rules, replacing bogus namespace-name() [insufficiently tested. oh well.] - added an ID for reach rule and normative assertion - tweaked editor's draft status a bit (postponed an index of rules/assertions) Revision 1.254 2007/04/24 05:22:45 connolly todo += more XHTML than just DTD-valid, base in XHTML Revision 1.253 2007/04/24 04:48:27 connolly fixed mechanical rule for multiple rel values Revision 1.252 2007/04/24 03:39:42 connolly - added normative reference to test cases, cited from introduction -- removed reference to td/testlist1 from status section - in 1st normative assertion, cited XMLBASE in addition to IRI spec - noted grddlonrdf-xmlmediatype test case to clarify what counts as an RDF/XML document - clarified that "transformation" may appear among others in the list of values in a rel attribute (mechanical rule is not yet fixed) - deleted TODO to wordsmith the GRDDL agent local policy stuff further Revision 1.251 2007/04/23 14:30:51 connolly when introducing mechanical rules, note that the audience is limited, per jjc Mon, 23 Apr 2007 14:10:39 +0100 Revision 1.250 2007/04/18 14:54:08 connolly todo += Clark 17 Apr on issue-mt-ns, identifying RDF/XML Revision 1.249 2007/04/06 03:14:09 connolly todo += @rel is space-separated Revision 1.248 2007/04/06 03:12:29 connolly another occurence of space-separated token in definition of 'metadata profile name' Revision 1.247 2007/04/06 02:50:17 connolly in section on transformation algorithms, advised against dependency on external DTD subset per suggestion from jjc 30 Mar 2007 13:32:07 +0100 Revision 1.246 2007/04/06 02:34:42 connolly section typo Revision 1.245 2007/04/05 22:57:37 connolly re-phrase the dc-extract.xsl paragraphs to use "faithful rendition" rather than "meaning of the document" consider citing test cases normatively Revision 1.244 2007/04/05 22:40:01 connolly - clarify "space-separated token" per jjc 27 March - note the possibility of other output formats and the relevant test case in the algorithms section - todo += jjc on validation Revision 1.243 2007/04/04 15:04:02 connolly move normative references inside the normative rule boxes for base IRI, RDF Graph, XHTML family document, profile attribute per suggestion from jjc Tue, 27 Mar 2007 11:42:32 +0100 Revision 1.242 2007/04/04 14:59:19 connolly Clarify that grdd:namespaceTransformation triples implied by RDFS/OWL don't satisfy the premise of the rules, per suggestion from jjc Tue, 27 Mar 2007 11:42:32 +0100 Revision 1.241 2007/03/29 19:51:01 connolly considering citing Infoset spec re xml:base Revision 1.240 2007/03/28 16:06:52 connolly comments todo Revision 1.239 2007/03/28 15:29:13 connolly todo += more on mime types under transformations Revision 1.238 2007/03/28 14:51:54 connolly todo+= conneg/local policy, per jjc 28Mar Revision 1.237 2007/03/02 03:59:52 connolly in namespace document excerpt, it's rdf:Property not rdfs:Property