Re: Fresnel: Styles: summary and unsolved issues

From: Chris Bizer <chris_at_bizer.de>
Date: Tue, 26 Apr 2005 00:03:10 +0100

Stefano,

if we would drop fresnel:Styles what would we do with fresnel:label,
fresnel:value and fresnel:contentAfter?

Would we:
1. Move this functionality into the lens.
2. Keep it in something seperate, maybe not called style, but which also has
a domain property.
3. Also drop this functionality?

Chris

----- Original Message -----
From: "Stefano Mazzocchi" <stefanom_at_mit.edu>
To: <general_at_simile.mit.edu>
Sent: Monday, April 25, 2005 5:22 PM
Subject: Re: Fresnel: Styles: summary and unsolved issues


> 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 - 22:02:45 EDT