Hi Stefano,
Thank you for your comments.
The paper uses an RDF (N3) syntax for explaining Xenon, but our intention
was to use it as a canonical means for describing the language in the
context of a research conference rather than to make a statement about how
N3 is the ideal syntax for expressing stylesheets. Unlike XML, which has
been, in some sense, defined by its syntax, RDF has no such limitation.
What we have done in Haystack is to develop new syntaxes for RDF-based
languages in order to simplify the development experience on several
occasions.
I completely agree with you that many people won't have a "programmatic
mental model". This is why ontologies such as VOWL and Fresnel are
important: they allow people who want to express presentation knowledge to
do so at a very high level. The point of Xenon is to say that people who
_do_ have a "programmatic mental model" should not be locked out of using
VOWL and Fresnel simply because they hit the boundaries of what such an
ontology can express.
I believe we can resolve the two key problems of XSLT you bring up: (1)
the unfriendly syntax; (2) function calls having a bulky, second-class
status (xsl:call-template instead of just using the name of the function),
which forces people to be aware of the fact that they are programming.
Furthermore, as a result, I believe Model 2 is possible within Xenon for
the same reason that Scheme and Lisp are capable of implementing Model
2--because you can easily embed a mini-declarative language within them.
Best regards,
Dennis
Stefano Mazzocchi <stefanom_at_mit.edu>
12/08/2004 03:25 AM
To
general_at_simile.mit.edu
cc
Dennis Quan/Southbury/IBM_at_IBMUS, Richard Cyganiak <richard_at_cyganiak.de>,
karger_at_mit.edu
Subject
Re: Xenon and Fresnel
Chris Bizer wrote:
> What do you think about Xenon?
Xenon has the same values and the same problems of XSLT: for example,
the use of the XML syntax for XSLT drew way more criticism than plea and
the idea of using XSLT to transform XSLT itself is the tipical "solution
in search for a problem".
Moreover, the trend in template system design is always been to move
from what is called "Model 1" (where the context population and the data
presentation are in the same page, done by the same person) to what is
normally called "Model 2" (where the context population is done before,
normally in code, and the data presentation is done on a later stage).
There is general tendency (from all the template systems that have to
deal with real-life user requests) to move away from a Model 1 because
everybody realized that the people that are normally responsible for
creating the template don't have enough of a "programmatic mental model"
to use turing-complete languages and query languages (xpath for xslt,
rdql/sparql for xenon).
Of course, the above is a debatable point, but if I imagine anybody in
my group here at the libraries that has to write or even maintain a
Xenon template, I find myself thinking that I end up doing all the work
myself.
I don't question its power or elegance (I do question the choice of the
RDF model and syntax for describe it, which feels rather "golden
hammer"-ish to me, but that's another story), that's not where my
concerns reside, but I agree with Ryan that implementing Fresnel using
existing Model2-friendly template systems (such as velocity) is winner
in our usage context because, first: we don't have to write the template
system since it's already there and second: it's waaaay easier to
maintain since it's java code and simple pages with variable expansions
and a few conditionals and iterations.
Therefore, just like Ryan, I would welcome an independent implementation
of Fresnel using Xenon or something equivalent, but I wouldn't
personally spend any energy on that.
--
Stefano Mazzocchi
Research Scientist Digital Libraries Research Group
Massachusetts Institute of Technology location: E25-131C
77 Massachusetts Ave telephone: +1 (617) 253-1096
Cambridge, MA 02139-4307 email: stefanom at mit . edu
-------------------------------------------------------------------
Received on Tue Dec 07 2004 - 23:22:56 EST