This is the second part of my attempt at summarizing the current status
of Fresnel. See "Fresnel: Lenses: summary and unsolved issues" for the
first part.
-----------------------
II. Styles
-----------------------
Here comes the difficult part. I've tried to present Stefano's point of
view (which might eb shared by others) and mine (which I believe to be
shared at least by Chris) as a discussion. Stefano, I might have
misinterpreted part of what you said in previous emails. Please correct
me if that is the case.
Do we need styles in Fresnel, and if so what for?
My point of view: yes. Fresnel is about encoding RDF presentation
knowledge. Lenses tell you what to present, and maybe in what order.
This is not sufficient. We need something to say how to present it, how
to add some additional content, and how to style it.
Stefano's point of view: not necessarily. The selection part (based on
lenses) could produce a tree. This tree could then be manipulated by
XML-world technologies such as XSLT and CSS, or template engines that
would generate XHTML representations based on what is contained in this
tree.
My feeling about this: this has the advantage of keeping Fresnel very
simple and easy to implement, but Fresnel also looses a lot of interest.
Fresnel is no longer about encoding RDF presentation knowledge. It is
about encoding RDF selection and grouping knowledge (what data to show
together).
Stefano: the only advantage of representing presentation knowledge in
Fresnel is if it can be used by all browsers, i.e. if Fresnel "views"
are portable.
Me: I agree with that.
Stefano: considering that various browsers (e.g. Longwell and IsaViz)
are not based on the same representation paradigm (nested boxes ŕ la CSS
in one case, node-link diagrams in the other), there is very little of
CSS styling that we can share across such different browsers. Don't even
think about SVG. The representation paradigms are just too different. So
what's the point of encoding this in a browser- and
representation-paradigm independent manner? Sharing font and color?
That's not interesting enough.
Me: I see your point. But that seems to be were we diverge. I do not
consider the CSS/SVG/whatever part of Fresnel styles to play a central
role. That is not the most interesting part of Fresnel styles. In my
opinion, Fresnel is not about defining how to layout data, or even how
to *precisely* style it with instructions such as:
"display:table-cell;padding-top:1em;border-bottom: 1px solid black".
For me, Fresnel is about encoding display *knowledge*, not precise
instructions. We are not inventing a new styling/layout language such as
CSS, or even adapting it to RDF. I am more interested in more abstract
parts of fresnel styles, such as fresnel:contentBefore, fresnel:label,
fresnel:value, etc., i.e. the part of Fresnel styles that are RDF
specific. This is what counts for me, and this part *is* portable across
representation paradigms. I find it to be useful. At least that is what
I think.
You might then wonder why we have hooks to CSS and SVG? I'd say because
it is a part of the presentation process that is also important, and it
is nice to be able to encode it as Fresnel presentation knowledge. But
my point is that CSS and SVG instructions do not play a central role in
Fresnel stylesheets. They give indication of how to style content items,
but they can freely be ignored by browsers, depending on their
capabilities and representation paradigms. That's why I am ok with
allowing both CSS and SVG. If do not want *all* styling instructions to
make sense for *every* browser.
From there, in order to be representation-paradigm independent, we
define an abstract representation model. It is *not* a box model. It can
be instantiated as a box model, but it can also be instantiated as a
node-link diagram based model. It is up to the browser to map abstract
regions of this model (such as the property box, the label box, etc.
(*)) to actual graphical entities of the underlying representation
paradigm. Depending on these entities and how they relate to each other,
CSS and SVG instructions might be taken into account or ignored by
different browsers.
(*) Note that the current Fresnel manual does not convey this idea
properly yet, as it only gives an example instantiation of this abstract
representation model (based on nested boxes). Besides, the choice of the
term "box" for property box, label box, etc. might not be the best
thing. But I don't have any other idea right now.
I am not saying that this solution is perfect. I just wanted to give my
point of view in a (hopefully) clear manner.
Besides, I do not reject Stefano's proposal of an intermediate tree as
the result of the selection process. I don't think this format has been
clearly defined and I'd like to hear more about it. However I do have an
question about what I've heard: this <div>-based tree structure just
looks already too Longwell/CSS-oriented to me. Stefano, you've been
arguing that Fresnel should not define an implicit layout method. I
entirely agre with you. But doesn't this tree structure already goes
down this path? I'm not saying it does; it is just the impression I get
from it.
One last point: Lloyd makes a good point when he says:
"Working equally well for everyone often means not working well enough
for anyone (anyone working with a consensus-driven organization knows
the dangers of aiming to make everyone perfectly happy ;) ). My guess
is that you just need to choose and commit."
So if a majority of people is in favor of restricting the representation
paradigms supported by Fresnel, we can go this way.
--
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 FRANCE http://www.lri.fr/~pietriga
Received on Sun Apr 24 2005 - 11:43:33 EDT