W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2003

Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

From: Graham Klyne <gk@ninebynine.org>
Date: Mon, 27 Oct 2003 16:39:11 +0000
Message-Id: <>
To: Emmanuel Pietriga <epietriga@yahoo.fr>
Cc: www-rdf-interest@w3.org

Indeed so.  But I still think your idea is a good one to investigate.

What follows are some disjointed ramblings, which you may well choose to 

I'm no expert on XSLT, but it seems that the behaviour of 
<xsl:apply-templates /> is to use some context from the template that 
invokes it, and use that in performing a further query.  In the case of a 
tree query, the subsequent query may be quite clearly scoped.  In the case 
of a graph query, I think the scope is not so constrained because the graph 
may contain loops back to "higher" notes.

One touchstone might be this:  given an RDF graph that follows a strictly 
tree pattern (and RDF graphs used to represent frame-like information do 
tend to follow such a pattern) then the [default?] behaviour should be 
similar to normal XSLT behaviour.

So, if one imagines an RDF graph that has a single "source node", and which 
contains a strict branching structure, how might this work?  The initial 
query (I think of RDFpath as likely being RDF-query-like) must somehow 
select (by name, or otherwise) the source node, and then describe paths 
from that node, or related to that node.  For each matching query, is it 
possible to identify a new node that serves a similar role to the original 
"source node"?

Then consider the ways in which an RDF graph may be not-tree-structured:

- There is no single source node:  maybe the root context must be 
considered to be a set of nodes?  E.g.  I have found that graph queries 
might start with something like "find all nodes of a given type", and 
starting from these, paths through the graph can be traced by subsequent 

- branches may recombine, so that leaf nodes are shared between 
branches.  This might still be processed as if it were a tree, if the 
duplication thus engendered is not harmful.

- the graph may be cyclic.  One view might be to treat this as an infinite 
tree.  (Something like this happens for the description of recursive 
functions in functional programming language implementation.)  Another view 
might be to use some kind of dictionary to avoid chasing round loops -- 
such a dictionary might represent a new graph querying context (is this 
similar to tabling of predicates in Prolog derivatives like XSB?)

- are there any other patterns that break the XSLT tree-scanning model?

Set against these complications is the fact that the primitive relations in 
an RDF graph are simpler than child relations in an XML tree:  there are no 
attributes vs child elements to worry about, with different rules for 
ordering and duplication.  There are no special properties that demand 
treatment differently from other properties (other than possibly for 


At 16:46 27/10/03 +0100, Emmanuel Pietriga wrote:
>Beyond the RDFPath problem, there are other problems to solve, like what 
>is the semantics of xsl:apply-templates in the context of an RDF graph. We 
>don't have a tree here, so what does:
><xsl:apply-templates select="*" />
>mean when applied to the context node of an RDF graph?
>Graham Klyne wrote:
>>At 12:59 24/10/03 +0200, Emmanuel Pietriga wrote:
>>>I agree that it is something useful. But isn't this what XSLT already 
>>>does? That's what it does for XML. So why couldn't it do it for RDF? I 
>>>mean, except for the XPath part that is not (as discussed yesterday) the 
>>>best-suited technology to address nodes and arcs of an RDF graph, XSLT 
>>>seems to be well-suited to this task (all that is needed is to replace 
>>>XPath selectors by *RDFPath* selectors).
>>I think that's a really interesting idea...  using the existing XSLT 
>>design to its strengths and directly addressing its weakness with respect 
>>to RDF data.
>>Graham Klyne
>>For email:
>Emmanuel Pietriga (epietriga@nuxeo.com)
>tel (mobile): +33 6 88 51 94 98

Graham Klyne
For email:
Received on Monday, 27 October 2003 13:31:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:45 UTC