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

Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

From: Emmanuel Pietriga <epietriga@yahoo.fr>
Date: Fri, 24 Oct 2003 12:59:51 +0200
Message-ID: <3F990627.8030901@yahoo.fr>
To: Reto Bachmann-Gmuer <reto@gmuer.ch>
Cc: www-rdf-interest@w3.org

Reto Bachmann-Gmuer wrote:

> More perspectively I think that a styling vocabulary that allows setting
> CSS/FO/SVG properties (GSS) and allows to define how the styled resource
> should be serialized to HTML,XSL:FO or SVG would be possible and useful.

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

GSS as it exists today does not work on an output format. It uses CSS 
and SVG properties to influence the representation of the model 
displayed as a node-link diagram, abstracting over its source 
representation (which actually is SVG, but that does not matter).

> I think two incompatible point in the approaches are:
> - - GSS if for rendering whole models, RDFStyles for rendering a Resource
> (expanding its properties).

true: unless you use specific properties like display=none or 
visibility=hidden, all nodes and arcs are displayed. Those for which no 
style is defined are displayed using the default styles.

  I've chosen this approach to avoid the
> problem of determining the root in (circular or multi-trees) models and
> because I guess that it is more applicable to distributed models (only
> queries for statements with a defined subject)

In this respect, I believe that GSS and RDFStyles are different in the 
same way that the 2 XSLT modes are different (source-driven 
transformation and target-driven transformation).

> - - An RDFStyles is a Resource (containing a sequence of renderers
> (=templates)) not a model. With this it is possible to determine the
> priority of (conflicting) renderers and, more important, I think that i
> should always be possible to merge two models without loosing
> information so I avoid (implicit) references to the model containing a
> resource/statement.

I'm not sure I follow you on this point. How do you determine priorities 
exactly of conflicting renderers?


Emmanuel Pietriga (epietriga@nuxeo.com)
tel (mobile): +33 6 88 51 94 98
Received on Friday, 24 October 2003 06:59:05 UTC

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