Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

Reto Bachmann-Gmuer wrote:

> 
> Emmanuel Pietriga wrote:
> 
> | 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).
> For the RDF processor an XSL template is just a literal or an external
> resource. This may not be a problem in many cases, but having the styles
> in rdf allows to:
> - - deliver a speicific style for rendering the result of a query without
> unneeded templates
> - - use inference engines on styles
> - - use an optimized triple store instead of parsing text
> - - write content and style using the same syntax and tools
> - - multiple styles can be used to generate one output without the styles
> having to know/import each other

I agree that having a stylesheet language based on RDF has advantages. 
GSS is RDF-based too. However (and as GSS shows), the RDF layer brings 
significant complexity to the stylesheet language. So there are also 
drawbacks.

As we discussed earlier, one solution is to have (specialized) 
front-ends for authoring stylesheets. But there are also many geeks out 
there (including me) who like to write their documents and stylesheets 
by hand. And generally-speaking, it is not a good idea to have a 
heavy-to-use language with a cumbersome syntax, even if there are good 
graphical front-ends for it.



> | 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).
> In a GSS/RdfStyles you would have one layer where you set format
> independent sytling attributes and one where you can defined how a
> resource with certain attributes is serialized to a character stream.

Couldn't we restrain the serialization to an XML structure instead of a 
character stream? This would add a level of abstraction and make things 
easier (probably).



> |> 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.
> the point is if the thing being rendered to a document is e.g. a
> foaf:Person (which may render other 'foaf:Person's recursively) or the
> model represented in a foaf-file.
> |
> |>  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).
> |
> Hmm, I don't see the analogy, If I didn't missunderstood some basics GSS
> and RDFStyles are both source driven.

GSS is clearly source-driven. My mistake. I thought RDFStyles was 
target-driven (probably because someone talked about this at some point).


> |> - - 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?
> the first renderer in the rdf:Seq is executed, the renderer can
> optionally say that the next matching renderer should be executed too
> (this feature will be in the next version). With this you can have first
> some renderes that do not produce output but only set some variables and
> forward the rendering-request and a later renderer that generates output
> using the variables set by the previous renderers and which does not
> forward the request.
> 

that's interesting. In GSS, a sequence of matching templates is 
computed, sorted by a criteria of longest match. The first one is 
applied to the selected entity (node or arc). If there remains styling 
properties to be set, the GSS engine looks into the list of matching 
templates if a template defines these properties and applies them. It 
would be nice to allow a template to forbid the evaluation of other 
templates even if it does not set all styling properties.

Emmanuel

-- 
Emmanuel Pietriga (epietriga@nuxeo.com)
tel (mobile): +33 6 88 51 94 98
http://claribole.net

Received on Tuesday, 28 October 2003 08:34:54 UTC