Dropping, Jacco's email from CC since he subscribed to general_at_.
> I'll send my comments on you paper in little bits and pieces,
> depending on when my baby son allows me. I hope you'll forgive the
> fragmented, scattered comments, but I figure with the deadline you
> need them sooner more than you need them all at once. I hope you and
> Jacco also forgive me if I've read his email too quickly and ended up
> repeating (or contradictly!) what he wrote.
not a problem! thanks a lot.
> Like Jacco, I have paper comments and I have technical comments. I'll
> focus on the paper comments first. I agree with what Jacco wrote in
> his two emails. I really like your work. Like Jacco, I'll be mostly
> writing what I suggest be changed, but for each thing that sounds
> negative I have 10 unwritten opinions that are quite positive. I
> expect these positive opinions will become clear over the longer term.
>
> But firstly, I'm not sure you have the latest Noadster demo link:
> http://homepages.cwi.nl/~media/demo/cuypers/ . This lets you choose
> different repository, type a search string, set some clustering
> parameters, get the global and local views, and (most relevant for
> Fresnel) see and surf the local views.
[my ego is pleased to know that you are using cocoon for your demos ;-)]
> I share Jacco's primary comment about the paper: that it is more a
> demo paper than a research paper. You worked hard on a format, and
> much of an implementation, so it's natural to write "here is what we
> built". The first change I would do it, keeping most of the same
> paper content, turn the motivation upside down as follows. Start with
> the problem. Set requirements. Argue best practice. Chart a general
> framework encompassing these two. Use the Fresnel format and
> implementation as one of multiple examples illustrating this
> framework. Fresnel is well underway, but remains incomplete. If you
> believe some of the comments we write about Fresnel, you may be
> motivated to change things, and thus Fresnel may not perfectly fit the
> framework. But since the paper would be about the problem and
> framework instead of about Fresnel, you can simply comment on what
> should or could be added and changed in Fresnel. Fresnel would be
> just one of many sample illustrative implementations, and you could
> discuss it in the same way as the others: each illustrates some
> aspect(s) of the framework, either by what each does now or what each
> could do with minor alteration or extension.
>
> I see the research problem as "Stylesheets for Semantics".
well, see, I disagree with that: I think the problem is "graph
presentation" not "stylesheet for semantics".
> 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.
> 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.
> 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.
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.
I do worry though, about how fragile the consensus even between us
authors is, this is not a good sign.
> Of course, putting all these features in CSS depends on CSS selection
> being able to select what's required. This brings us to another
> requirement of CSS for XML/HTML/SVG: that you can select what you need
> to. CSS selectors use particular aspects of current context in XML
> structure. How much can these be used for semantics?
An analysis of previous work is yet to be written.
> I really like your idea of a generalized presentation structure for
> semantics, the container/box model. We did this for Noadster, but
> without knowing it, and thus without formalizing it and doing it
> right. Noadster's local display has a particular HTML subset. We
> were choosy (though not formal or perfect) in the relationship between
> our CSS stylesheets and Noadster's sub-HTML.
We are just a little bit more formal, but far from being perfect, I fear.
> 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.
> I'm interested in seeing how readily Noadster's
> local view can be done in Longwell and Fresnel when the new public
> download is available in a few weeks (right?). Looks like a good fit.
I will let Ryan comment on the release dates.
> So how can CSS select adequately (and best) into this model? The
> class attribute in both HTML and SVG let you do so, as long as the
> (generated) HTML and/or SVG have corresponding classes. How about
> giving the components of your box model formalized class names?
It is currently possible to define a class out of the selection process,
but there are no explicit classes about the box model. I agree it would
be a good thing to have, much more useful than an implicit box layout
paradigm.
> This
> strikes me as the primary, best practice means of styling based on
> role in the general model. Good implements allow the general
> exceptions, but only the primary means is worthing writing at length
> about in a research paper.
>
> 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?
> 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.
> 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.
> 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.
If this works or not in practice, is not something we can infer before
we even implement it or use it ourselves.
> A small comment is that I'd remove all discussion of SVG.
Yep, I agree, it's a can of worms.
> I can see
> why your motivated because of IsaViz, but while it is important for
> Fresnel, it conveys no addition research concept to the paper. It is
> also distracting because if you start with it then you need to say so
> much more than you do about what the SVG really does and how it gets
> layed out. And what you actually do, setting line thichness and
> color, seems trivial. I know what you're getting at, and like it, and
> you should keep working on it technically, but many reading the paper
> won't get it.
>
> Fatherly duty calls, but I'll write more later. I hope to write about
> how what is true for CSS above is also true for XSLT. XSLT's model of
> <xsl:apply-templates select=""> along with <xsl-template match="">
> correspond well to lens domains. I'd formalize this comparison by
> generalizing what XSLT does here, translating this to semantics, doing
> the same for any best practices, and then using illustrative examples
> from Fresnel. Another illustrative example is a paper by Jacco:
>
> Jacco van Ossenbruggen, Lynda Hardman, and Lloyd Rutledge. Combining
> RDF Semantics with XML Document Transformations. In: International
> Journal of Web Engineering and Technology (volume 1, number 4), 2005
> Note: to be published, based on
> http://ftp.cwi.nl/CWIreports/INS//INS-E0303.pdf .
>
> There may be useful tidbits in this paper for you. Primarily, the
> paper's implementation of calling RDF from XSLT, and the necessary
> theory behind it, provides some useful illustrations of what your
> approach to semantics stylesheets can/should/must do. In particular,
> this paper's means of refering to RDF structure (as XML-ified by
> Sesame RDF query language returns) applies to your paper's lens domain
> selection by both the template/select/match general trigger model and
> also how Jacco used XPath in context of the Sesame-generated XML. Your
> approach is a cleansed, purified, ideally generalized formalization of
> this (and more, of course).
>
> Now fatherly duty is *really* calling ...
>
> More to come,
keep them coming!
--
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 Fri Apr 22 2005 - 14:14:00 EDT