Re: ANNOUNCEMENT: RDFStyles: alternative to XSLT for RDF

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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

reto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE/mTJ4D1pReGFYfq4RAqRqAKCPWYfKnObPUiyjQjv6TRtk4vO8sgCgiSBJ
PYg5pMt8j6VCsv+BQkDTQ50=
=TjKv
-----END PGP SIGNATURE-----

Received on Friday, 24 October 2003 10:08:20 UTC