Emmanuel,
thanks so much for restarting the 'harmonization' process with this
email! You described my concerns very well (and I'm also glad for having
got my message across).
Emmanuel Pietriga wrote:
> 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.
I'll focus my energy on the 'styles' part for now. I'm sure it will be
easier to reach consensus on the lenses part since we pretty much all
agree on those.
> -----------------------
> 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.
No, I think you captured my concerns very well.
> 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.
I wish to add something: the main reason why I became more and more
hostile to the style part over time is that I started to think about how
to implement it and it appeared to me that the style part adds
complexity at the implementation level without much benefit.
for example, if I want to specify that a "label" is the left column, the
"values" are the right column, I have to use display: table-cell... this
means that I have to use a CSS parser, but also *interpret* the CSS
display vocabulary, transform it into the equivalent XHTML element
(because if I want browser portability, I can't hope that that CSS style
will work!) and use that.
now, you might say, c'mon that's not so hard. Sure, it's doable, but
that's my cost, what's my benefit?
The benefit is view portability: by declaring all the 'presentation
info', the browsers are able to interpret the way they want and by
reusing exisint vocabularies, we can be as layout paradigm-abstract as
we want.
Now, I did a reality check of the above and found out that since we aim
to be cross platform, there is a very small overlap between the various
layout paradigms... which means that the various fresnel interpreters
will have to "guess" on how to adjust somebody else's views to their
models, which means that 'portability' of view is just a myth, it will
just look different in every aspect.
So, if the only reason to have the style part is view portability *and*
in order to achieve portability the abstraction is very high *and* in
order to interpret this abstraction interpreters will have to do a lot
of guessing *and* by doing this they will destroy the portability of the
view... then why are we doing it?
> 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).
Hmmm, I'm starting to feel that we are saying the same thing but with
different terminology.
Personally, what I think we need is a way to layout a tree from a graph.
This is what Jacco, Lloyd and friends did with XSLT, but it's hacky and
feels wrong.
But the missing bridge is *that*: here's a very complex graph, give me a
tree and I'll take it from there.
Can we make those "graph->tree bridges" portable? yes.
Are fresnel lenses enough to come up with that tree? no! as you
mentioned below, contentBefore, contentAfter and all those things are
what you need for that.
Now, are we going toward Xenon? no! Xenon is a turing complete language,
we need to stay away from that. The workflow should be pipelineable:
model => transformation => selection => tree construction -> styling
where => passes a graph and -> passes a tree. Xenon belongs in the
'tranformation' phase, we must stay clear of that part since it's pretty
nasty (see how XQuery and XSLT merged the two even if 90% of their use
was just selection and tree construction! and now people are scared away
from them because too general and too complex)
Selection is rather hamless since it's very declerative. Lenses cover
that part.
The problem I'm having is that fresnel styles cover both tree
construction and styling, but without defining an intermediate
representation that people can use if they don't think the styling part
of fresnel is helpful.
My point is: if a fresnel interpreter would have to guess anyway on how
to interpret the style instructions in a particular environment (which
is not just just boxy vs. nodes-and-arcs), then I would much rather have
it to guess on font color and font type than space occupation on the canvas!
> 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.
Glad to hear that.
> 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.
Bingo!
This is what I called above the "tree construction" phase. What fresnel
does, is to repeat the HTML "font" tag mistake, but in a such a very
abstract way that it was hard to see.
Fresnel currently can encode *all* the presentation information *inline*
in the resulting model, leaving the problem of presentation to the
underlying interpreting subsystem. This is exactly the problem that CSS
was born to solve.
I think it would be way more useful if Fresnel 'styling' was just
renamed 'tree construction', where tree means a very abstract notion of
ordered, nested content, with 'class' information (label, values, etc..)
that one could use as 'hooks' for further processing.
Then both you and I would be happy: we don't really care if your title
is red and my title is blue, that's not the point, the point is that we
both come up with the same title, given the same model and the same
fresnel view, and that it's reasonably easy for the both of us to style
that title in a way that it fits our respective layout paradigms (being
boxy XHTML+CSS, boxy Swing, boxy SWT, nodes-&-arcs SVG+CSS, N&A Java2D,
boxy VRML, etc..)
> 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.
In my view above, the ability to 'embed' CSS instructions inside the
fresnel results is equivalent to the 'style=""' attribute of XHTML/SVG
and I do admit that I have found that useful, mostly in cases where I
just need a little modification in a particular space (mostly padding,
margins) but not general/reusable enough to make that a CSS class.
But keep in mind that some argue that when you need inline CSS is
because your CSS design is flaky. And I see their point.
> 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.
Here is where I disagree: the complexity of a specification is critical
for its adoption. I believe that the style part is overly complex for
its real value.
i think the spec would be simpler to write, simpler to read and simpler
to understand, use and implement, if the style parts was transformed
into a 'tree construction' part and style forgotten, a lot of the
complexity would go away.
And at what cost? no cost! since even you admit that view portability is
a myth anyway!
You say that it's better to have it and then let users (and
implementations) ignore it.
I say it's better *not* to have it and let users style the result tree
as they want (and as they already know how!!).
> 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.
Great, we are definately converving.
So, let's say that the output of the tree construction phase was
something like
<div class="items">
<div class="item">
<div class="title">Blah</div>
<div class="author">
<div class="label">author</div>
<div class="value">Joe Random</div>
</div>
...
</div>
...
</div>
this is *completely* equivalent to
<items>
<item>
<title>Blah</title>
<author>
<label>author</label>
<value>Joe Random</value>
</author>
...
</item>
...
</items>
and if we encode all the information that styling interpreters would
need to make the best use of that information (for example, datatypes or
originating namespaces), then the above could be transformed/interpreted
into whatever layout paradigm.
NOTE: if we add <?xml-stylesheet ?> PIs to the above tree, we could also
make those font colors portable! With reduced complexity of the whole thing!
> (*) 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.
Fair enough.
> 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.
I've shown above how the two trees are just different encodings of a
similar infoset. I'm not in favor of one versus the other, as long as we
have a defined way of achieving it.
> 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.
No, there is no layout model in the examples above, I am just implicit
relationships with nesting (in the XML-ish way). The fact that tree
nesting is mapped directy into box nesting in a boxy layout should not
trick you: even SVG elements are nested, but the visual semantics
associated with that implicit relationships are defined by the layout
paradigm.
Things are not implicit, they are undefined, on purpose, to avoid people
believing that something that is 'defined' means 'portable' and since we
can't possible guarantee that, we just don't define it at all.
> 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.
I don't think we need to restrict the representation paradigms: I think
we need to understand what we portability we can guarantee and what we
cannot and draw a line there.
My model above allows for even *more* representation paradigms of
Fresnel output, just avoids pretending to be able to be abstract enough
to describe the presentation information in a such a way that one would
write one fresnel lens and use it everywhere.
It ain't going to happen! I'm not going to download a random lens from
another web site and stick it in my layout that I paid 100K a web design
firm to come up with!! Forget it. I'm not going to write an interpreter
that gets a fresnel lens targetted for SVG and tries to understand how
to layout that so that all the text fits in the little box the page
forced me into!
Would you?
--
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 Mon Apr 25 2005 - 16:21:18 EDT