Summary: considering that view portability is a myth (from the pure
styling/layout point of view only), and considering that my fear of your
proposal being too nested-box oriented is unfounded, I think your
proposal is valuable and that we should favor it. However, we need to
precisely define this intermediate abstract tree representation. And we
need to address Chris' question: if we drop styles as they are currently
defined, where do we specify fresnel:label, fresnel:contentBefore, etc.
More details below.
Stefano Mazzocchi wrote:
> 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?
As I said before, I agree that the CSS/SVG/whatever part of what we call
Fresnel styles is not portable. The other part is (contentBefore,
value,...). And that is the important part for me. So we basically
agree, and I am ready to dump the CSS/SVG part of Fresnel styles (which
should no longer be called Fresnel styles).
> But the missing bridge is *that*: here's a very complex graph, give me a
> tree and I'll take it from there.
ok.
> 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)
agreed.
> 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.
this is true. But until now I did not consider this as a big problem,
because of the way I see Fresnel-aware browsers (see comment just below).
> 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!
Our initial divergence may have come from the fact that we seem to be
seeing browsers in different ways.
I'm not sure about this, but to me it looks like you see Fresnel-aware
browsers as dumb applications that can't do anything unless we tell them
explicitly what to do from A to Z (much like a Web browser). Something
like: "Oh my god! what I am going to do with these styling instructions.
I have no predefined layout model for that. What does this guy want?
What am I supposed to show? Help! I want to look like my friends.".
I was rather seeing Fresnel-aware browsers as smart applications which
know what they're doing. Applications you might qualify as presumptuous,
that would say "Ok, what have I got here? Fresnel styles! Don't tell me
about layout, I'm cool and I know how to handle it my own way. You
don't. But let's see if the instructions you give me make sense. If they
do, I'll apply them.".
Your proposal of an abstract tree representation gives more freedom
w.r.t the kind of browsers and tools that can process Fresnel
stylesheets. I now realize that Chris and mine might ask too much from
applications, up to the point where it no longer make sense to share
styling knowledge.
> 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..)
Essentially you are proposing that we split styles in:
a) 'tree construction' that more or less covers the RDF-specific part of
Fresnel styles (contentBefore, label, value)
b) and 'actual styling' that handles font, color, layout, etc.
a) produces an abstract tree in which nodes have class attributes that
indicate whether the node represents a resource, a property, a property
value,... b) is not actually defined in Fresnel, but is left to each
browser's interpretation which defines what languages (CSS, etc.) to use
for laying out and styling the tree, using the class attribs found in
the abstract tree.
Ok. I'm ready to go this way. One thing though: how specific do you
intend the 'class' information to be? A controlled vocabulary such as
class="resource | label | value" is not enough. One might want to style
a given property differently from another one, maybe depending on its
value, or on the subject's other properties. So we need to be able to
apply styling instructions based on more information than just "this
node in the abstract tree contains a property label". Since styling will
apply to the abstract tree, and not the source RDF graph, some RDF
information will be lost. How far do we want to go w.r.t what is made
available in the abstract tree?
>> 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.
Ok, so this is answering part of my above question about what
information about the source RDF model is available in the intermediate
tree. We still need to define exactly what we put in it.
> 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!
Can you give an example of this?
>> 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.
Yes. I think I prefer the second one, but I don't have a strong opinion
about this. If we go the <div class=""> way, I'd rather use Jacco's
proposal (SVG's 'g' element). It looks more abstract to me.
> 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.
Cool.
> 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?
Probably not. I don't have 100K ;-)
What do other people think about this? Are we all ready to go the
intermediate tree 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 http://www.lri.fr/~pietriga
Received on Tue Apr 26 2005 - 08:08:25 EDT