cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] since we are at it, more irons in the template fire: Xenon
Date Wed, 08 Dec 2004 17:10:09 GMT
Now, let me tell you a story about templates.

My group here at MIT has the same problem with templates. We are 
currently using velocity, but we are moving our metadata browser 
(longwell, http://simile.mit.edu/longwell/) to cocoon.

The first (and easy porting) solution would be to keep using velocity, 
but in the longer run, it would be much better to use CTemplate.

At the same time, we are in the process of creating a RDF presentation 
ontology that we call "Fresnel" (kudos for our friend Mark Butler for 
the name). You can think of Fresnel as "CSS for RDF".

Fresnel is supposed to bring some more unity to the force in the space 
of RDF visualization, work pioneered by some other projecs like the 
Haystack project at MIT (http://haystack.lcs.mit.edu/), the IsaViz 
project at W3C (http://www.w3.org/2001/11/IsaViz/), the work by Chris 
Bizer and his group at the University of Berlin and Longwell itself.

Recently, a proposal for an RDF template language was put forth by the 
original creators of Haystack. It's called Xenon and it's basically 
"XSLT for RDF".

Find a copy of the paper here:

http://simile.mit.edu/mail/GetAttachment?listName=General&msgId=2687&attachId=1

WARNING: this will look at your eyes as extremely weird, but there are a 
few things inside that I consider valuable, so bear with me.

                                   - o -

First of all, Xenon is an RDF ontology.

If you don't know what that is, you can think at an ontology as a schema 
for RDF (even if there is no validation!, it just gives you a list of 
classes and properties that belong to a particular namespace).

The above means that, just like XSLT is XML, Xenon is RDF. As a result, 
you have to use RDF syntaxes (RDF, unlike XML has more than one) to 
write it. How does that look like? Here is with the N3 syntax:

:DefaultNameLens
   a xe:LensTemplate ;
   xe:role xe:nameLens ;
   xe:size xe:inline ;
   xe:match () ; # Matches everything
   xe:body [
         a xhtml:Text ;
         xe:body [
             a xe:Select ;
             xe:singleResult "true" ;
             xe:filter "PREFIX xe: 
<http://haystack.lcs.mit.edu/schemata/xenon#>
PREFIX dc: <http://purl.org/dc/elements/1.1/>
SELECT ?TARGET WHERE ($xe:target dc:title  ?TARGET)"
         ]
   ]

It is not important here to discuss Xenon per se (if you are curious, 
read my reply below.

http://simile.mit.edu/mail/ReadMsg?listName=General&msgNo=138

but there is definately a few things that are innovative (and came from 
the Haystack experience) and might be valuable in our current template 
discussion.

                                 - o -

The mental model of Xenon is composed of these elements:

  1) a template
  2) a query language for RDF models
  3) higher-level abstractions: lenses and views

We match on 1 and that's why I'm talking about ithere: Xenon is not 
meant to be an 'RDF transformation language' but it's meant to be a way 
to describe how you should annotate existing RDF with enough 
presentation information to allow visual browsers to display it and 
users to interact with it.

We match on 2) also, even if the approaches start to diverge: Xenon uses 
SPARQL (the still-working-draft W3C RDF query language. you can think of 
it as the alternative of XPath for RDF, since the notion of paths in RDF 
doesn't apply very well).

We do match on 2) even if Xenon names it "query language" and we name it 
"expression language". Both are a way to "identify" a particular datum 
or data in a model (Xenon expects everything to be an RDF model, we 
expet it to be either a collection of java beans or an XML DOM tree).

Note how, in this respect, Xenon is more straightforward since it has 
only one 'query language' while we have agreed to have at least two (the 
  java-like and the xpath-like).

On the other hand, we expect our expression languages to be easy enough 
for non-programmers to understand, while this is clearly not true for 
Xenon where writing a single SPARQL query requires extensive knowledge 
of both RDF and the mental model of querying.

In this respect, Xenon is clearly inferior (even with a non-RDF syntax), 
since no template designer will be able to write a Xenon template.

The big difference and the main reason why I brought it up is that Xenon 
has #3 which is something we might be interested in.

                                - 0 -

The haystack project soon realized that there are several ways to look 
at the same data. They tried to create a model where those "views" could 
be reused and applied even to data that was not meant to be displayed 
that way.

Example: you have a calendar view and a collection of events. Pretty 
straightforward. But then you have a collection of emails, with dates, 
and you apply the calendar view: result might be, for example, the 
chronological layout of emails, as they were events.

As "views" represent a way to look at a collection of data, they also 
realize the need to have single data objects or smaller datasets, as 
another form of visual granularity. They call these "lenses".

[The same concepts and terminology of views and lenses is now being used 
in Fresnel as well, while Fresnel is a purely declerative language, just 
like CSS, therefore nothing useful in our template discussion]

The difference between a view and a lens is rather subdle: since Xenon 
does not expect the RDF model to be pre-processed (as we do in our 
template system, by having a controlling stage up front before the 
pipelined view invocation), it has to perform some data selection to 
identify.

Here the two models different entirely: Xenon is a pull model, while our 
templates will be a push model (the data population will be performed by 
a previous, fully programmatic stage)

So, a Xenon view performs the "population" of the real template data 
model. Note how this makes Xenon a "Model 1" language.

Once the population is performed, the lens come in place to decide how 
to further present the data that has been selected by the view. This 
follows the declarative-matching model of XSLT, only using SPARQL 
instead of XPath.

We have agreed to identify this declarative-matching model harmful for 
our users, since people seem to be more used to a procedular description 
of their pages, even if this ends up being more verbose.

The use of the apply-template "procedular flow black hole" 
(anti?)pattern puts Xenon in the same category of XSLT.

                                  - o -

So, it seems that Xenon is just an double-staged RDF-oriented version of 
XSLT used ad a template, and we all pretty much agree that those mental 
models are too hard for template designers to work with, so why talking 
about it?

I like the name (and the concept) of lenses.

We have identified the need to have "isolated and reusable programmatic 
artifacts that know how to transform something into SAX events". They 
were named 'taglib' because the syntax normally used to identify them is 
a namespaced element (a 'tag').

The problem with the name is that it has been used (and abused!) in too 
many systems and brings memories of abuse and FS. Like the infamous <if> 
tag (also abused by XSLT)

I think we should call our CTemplates taglibs "lenses" instead.

WDYT?

-- 
Stefano.


Mime
View raw message