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.
Received on Wed Dec 08 2004 - 17:10:01 EST