Re: AW: intermediate representation

From: Emmanuel Pietriga <>
Date: Mon, 09 May 2005 07:24:14 +0200

Stefano Mazzocchi wrote:

>>> Because I think the separation between representing/exchanging general
>>> display knowledge and the actual output format.specific rendering
>>> process is
>>> very important, I see the role of styles/lenses and the intermediate
>>> tree as
>>> follows:
>>> 1. General selection knowledge is represented using lenses.
>>> 2. General browser- and output-format-independent styling knowledge is
>>> represented using Fresnel styles.
>>> 3. Both Fresnel styles and Fresnel lenses are used as *input* to
>>> generate
>>> the intermediate tree.
>>> 4. The intermediate tree is transformed *afterwards* according to the
>>> browsers visualization-paradigm, intended output format and also
>>> parameters
>>> like screen space available.

> Hmmm, maybe I'm not understanding the the concept of an intermediate
> representation is to allow people to implement only half of fresnel and
> not the full thing. The complexity I want to avoid is #3.
> In your workflow, there is nothing 'intermediate' about the tree
> representation: you are creating *the* result rendering. What you do not
> understand is that for clients like haystack that *have* to drive the UI
> directly (unlike delegating that part to, say, Gecko), the creation of
> that 'afterwards' tree is totally unnecessary, as they could use the
> information out of #3 to drive the display directly.

I'm not sure this is what Chris meant. The styling part in #3 is only
about the 'non-presentational' part of our styles.

> The fact that I have fresnel specifying an intermediate representation
> or not is totally unimportant to me, what I care for is ease of
> implementation for our requirements.


> The workflow I have in mind is something like this:
> 1) get a model
> 2) apply fresnel selection and get a submodel
> 3) apply fresnel graph->tree operations (stuff like contentBefore,
> etc.., the 'non-presentational' part of our current styles)
> 4) obtain the tree
> [if you don't care about view portability stop here]
> 5) apply fresnel styles to the tree
> 6) interpret the results
> [this follows the Template+XHTML+CSS model that has been proven so
> effective in real life]

I suppose that what you call Fresnel styles in #5 is the
'presentational' part of Fresnel styles, and what is in #3 is the
'non-presentational' part. We have to find better terms for these two
BTW. If so, the only difference I see between this and Chris' proposal
is the fact that you separate lens from non-presentational styles more
explicitly, i.e., you say:

RDF model -> selection with lenses -> RDF model -> non-presentational
styles -> intermediate tree -> presentational styles -> result tree

whereas Chris was saying:

RDF model -> selection + non-presentational styles -> intermediate tree
-> presentational styles -> result tree

In my opinion both are more or less equivalent, unless you are
interested in making the RDF mode resulting from the pure lens/selection
process available. If we want that, then we need Stefano's solution.

> At the end of the day, the 'interpret the results' phase is going to
> create 'yet another' tree *or* drive a UI drawer directly (depends on
> the software and its location, on the server or on the client).
> A few notes:
> - the above shows no need for having fresnel styles as you can use
> anything you want to style trees after #4 without reducing portability.
> the fact that #5 is in RDF is, to me, a golden hammer instance as there
> are ways to route around that without losing view portability.

That's where people fail to agree. We decided to concentrate on the
steps that lead to this point (1+2+3+4 in your workflow), and then we'll
see whether it is relevant to go further, once we have grounded the
previous steps.

> - steps #2 and #3 can be implemented with Sparql only, but only in very
> minimal cases. Would Sparql introduce XQuery-like containment, Fresnel
> would be totally unnecessary, but there is no plan to do so (they want
> to follow the SQL model where containment and query aggregation was a
> separate concern... a good idea, because it avoids the query language to
> need to become turing complete, as Xquery did and became too complex,
> losing appeal). So, unlike what Chris says, what we were missing in not
> order, but the ability to aggregate different queries together and apply
> different 'classes' to them (which is what i call the graph->tree
> bridge). Sparql *could* a used as graph->tree bridge but it's not enough
> for our requirements, while Fresnel selection is.
> We can discuss about details on the syntax of the tree all day long, but
> I would strongly suggest to agree on the workflow first. If we can't
> reach an agreement at the semantic level, there is nothing we can do to
> fix it at the syntactic level.

Yes indeed. So the first question is which workflow do we want? Yours or
Chris? Which comes down to choosing whether we want the result of the
selection process to be available by itself.

Emmanuel Pietriga
INRIA Futurs - Projet In Situ    tel : +33 1 69 15 34 66
Bat 490, Université Paris-Sud    fax : +33 1 69 15 65 86
91405 ORSAY Cedex  
Received on Mon May 09 2005 - 05:23:07 EDT

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:18 EDT