Re: AW: Lloyd's comments on Fresnel and your ISWC draft

From: <Lloyd.Rutledge_at_cwi.nl>
Date: Sat, 23 Apr 2005 10:53:04 +0200 (CEST)

> [my ego is pleased to know that you are using cocoon for your demos ;-)]

Oh, yes. We're big fans.

> well, see, I disagree with that: I think the problem is "graph
> presentation" not "stylesheet for semantics".

Interesting. But are these two that different? I assume "graph
presentation" is presenting the RDF-defined node-edge semantic net and not
using SVG to present, though the later makes sense too. But given the
first, you have a graph and you want to present it. Fresnel is a format
for saying how to present a graph. It does so declaratively. It can exist
separately from the RDF it presents, and is a separate format. Isn't this
then a stylesheet?

>> Requirements, good practice, how to do it in general, and examples, of
which Fresnel is the flagship. You use existing style formats as the
basis for requirements and good practice, but the paper could be more
explicit about this, making this a top level methodology. "Here's what
CSS does for XML, HTML and SVG. Here's what XSLT with XPath does for
XML. What each does sets requirements: style for elements and style
for structure should do the same as style for semantics. The
established best practices for both apply to semantic stylesheets as
well."
>
> There are many ways to present a graph with existing technologies, the
problem is that all of them have some problems, I wrote an email about
this a little while ago, I still need to write that part of the paper.

Interesting.

>> Best practice for CSS with HTML/XML/SVG is that you should put all the
style in CSS. A CSS requirement is that people can make their own
stylesheets for documents and document classes, meaning that document
may refer to stylesheets, but users and designers must be able to
override them. Thus the paper's discussion about enabling inline CSS
and localized references to stylesheets is distracting. These
>> features in Fresnel are like the same in HTML: sometimes necessary or
useful in a small number of exceptions, but generally bad practice and
should be avoided whenever possible. I'd focus on providing
>> requirements and best practice, perhaps mentioning only briefly that
these "exception" features are provided as well.
>
> Since fresnel does *NOT* (unfortunately) define an intermediate
> representation, the idea of 'inline' is blurred.

By "intermediate representation" you mean a presentation structure, such
as simplified HTML, SVG or SMIL? I think the paper is more
difficult to understand without at least a default, or just simple
example, intermediate representation. HTML(-like) would be the most
familiar. You can emphasize that it is an example to emphasize the
broader applicability of Fresnel. The fact that CSS works on HTML, SVG
and general XML helps make it a good basis for applying its style
parameters across multiple presentation paradigms for semantic
browsing.

>> Some constructs directly in Fresnel are similar CSS "allowed
>> exceptions to best practice". Showing and hiding properties are
examples. The display property of CSS, with "none" and "inline",
provide this ability. The Fresnel constructs are still useful, but
only at a practical implementation level: they do not contribute to the
reseach, conceptual contribution (as I propose it).
>
> I disagree.
>
> We did not encode best practices, we tried to come up with a design that
allowed to fit the requirements on the table, including view portability
and maximum reuse of existing semantics/designs/languages.
>
> If our effort was just cataloguing a list of best practices in markup
languages and encode them in RDF, I would agree with you, but this is
impossible to do, since our requirements were not completely the same as
the other presentation languages.

Maybe "best practices" is a bad phrase. Requirements is certainly
important. Maybe I mean more "guiding principles" as the "top three" of
best practices, such as "separate style from structure". But even there,
I was proposing taking well-established guiding principles for CSS (and
XSLT?) and applying them to semantics (or explaining how they don't).
This is part of the larger methodology I proposed: place
semantic style/presenatation/browsing in terms of established
techologies and principles for the document web.

> Actually, most of the time, it felt like trying to put a cube in a round
hole: there are still several issues to solve, but a lot of work went
into finding a way to fit that cube into that round hole and I do
consider that an effort that is worth publishing, even without
> implementations, as a way to generate feedback from people that would
not stumble upon our web site by mistake.

This square peg in round hole problem is mapping between general
models. Phrasing the paper's problem in this way makes it appealing to
the research community. If you can describe how it does fit, how it
doesn't, and what we need to do to both the peg and hole to make it fit,
then there's a research paper contribution. With the document (and graph)
presentation models and architectures pretty well
established, what's need is a mapping to underlying semantic
structure. Like you said in the previous email, its a bridge from a graph
to a tree.

>> You might be able to see
>> this in the HTML and CSS in the demo. Our model was a two-column table
allowing multiple entries in the second "value" column. This works
much like Fresnel's formalized model. Which is why I'm glad you
formalized it.
>
> I'm not :-) see my previous email.

Does it help that CSS lets you override table properties? On one
hand, the box model can be in generalized span/div HTML, with some style
sheets applying table properties to it. On the other hand, CSS can
override table HTML elements with non-table properties. But, of course,
CSS can't make either one an SVG graph. When you try to be overly
general, you risk doing nothing. A generalized HTML div/span structure
than can be CSS'ed to tables (forms, database field/value listings) any
maybe a few other interesting things would help illustrate the paper's
points, even if it were presented as "one example".

>> The tricky part is (as you must know by now all to well) is having CSS
select based on semantics. If you can formalize the requirements here,
you can argue in a good researchy way what additional things Fresnel
needs, and under what circumstances. One way to maximize CSS is that
each Fresnel lens/style offer a CSS class name.
>
> hmmm, I thought this was possible today, Chris?

I'm sorry. I had gathered from the paper and spec that this was indeed
possible, and didn't mean to imply otherwise. I just meant discussing
this possibility more, because it is a bridge between Fresnel and a key
aspect of CSS styling for HTML that works for Semantics here too.

>> Fresnel-enabled browsers then add this class name to the list in the
corresponding HTML/SVG element they generate. This means that a CSS
sheet must be written specifically for the given Fresnel sheet, but all
the issues here are the same as in HTML, and it is considered best
practice in HTML. Designers just need to know the class names and what
they mean for a given document class (semantic domain).
>
> Yep, this is the model I like the most too. Unfortunately, we could not
reach consensus on the above since it breaks view portability and some
of us thought it was a necessary requirement for the usefulness of
Fresnel.

My feeling is that some of you are trying to be too portable. 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. Or take a layered
modularized approach. Or keep general with formally proposed specific
applications with your formulation, such as how to do with a table. Look
at the progression of any W3C Recommendation and you'll see how these
approaches and more have helped bring concensus.

>> It would be cool, and a nice research contribution for the paper, if
you give (maybe you have and I missed them) other ways that
>> cleverly let CSS as it stands select semantic structure.
>
> We talked about using fresnel selectors in CSS instead of CSS selectors,
but it feels wrong since there is no way to 'namespace' the selectors
and CSS interpreted would confuse them.
>
> We decided to stay away from there.

Yup.

>> Then wrap
>> up with what CSS *cannot* do but is needed for semantics. How then can
you provide this? Extend CSS for semantics? Or, of course, use
constructs in the semantic stylesheet. Thus you get to certain Fresnel
constructs. But there may be a distinction between Fresnel constructs
that are required for this and ones that merely allow practical
exceptions to best practice.
>
> I really dislike the term 'best practice' btw :-)
>
> If you take 10 web designers, you come up with 50 best practices, only a
few of them shared by all of them and many of which that disagree in
between them.
>
> Fresnel is not about codifying best practices, is about providing *a*
way to solve the problem that would work, hoping to reduce the
> variability of its usage to a minimum.

But the paper shouldn't be about "a way to solve the problem" -- it should
be about the problem and what the requirements are to solve it and how to
judge any potential solution, using your solution as one of many examples
as an approach to finding the best solution, or showing how to continually
improve. Otherwise you have a "demo paper".

> If this works or not in practice, is not something we can infer before
we even implement it or use it ourselves.

Maybe best practice is the wrong term. But this particular "guiding
principle" I'm refering to here (style in CSS sheet, not in deprecated
HTML attributes or current style="", with few exceptions) is a core
principle championed by the W3C, for which you work ;). Surely you've
noticed a lot of people feel strongly about it. Most
computer-literate folk who've make Web pages are familiar with the
principle. You even state this style/structure/content seperation as a
guiding principle in the paper. I don't mean you should say what's right
or wrong. The separation isn't a recommended practice so much as the
basis for a model and architecture that both the recommended practice and
the exceptions to it follow. The model/architecture
itself is key (in a paper, anyway).

-Lloyd
Received on Sat Apr 23 2005 - 08:52:28 EDT