Chris Bizer wrote:
> Hi Stefano,
>
> very interesting. Your mail really helped me to understand the differences
> between Ryan's and my approach.
Thank you. Keep up the great comments too! ;-)
> It seams that:
>
> + you are thinking about a pure stylesheet language, that why you don't like
> conditions and additional content.
no, wait. What I'm saying is that you need two things: content and style
and that separation of these two is critical. I think everybody agrees here.
The subdle difference is that on the client side, the content is given
to you, it's a finite resource and there is no selection going on (if
not during dynamic user interaction but that's another story).
On the server side, the 'content' is not clearly defined and, in
general, it's a lot more than you can fit in one page (otherwise, you
would have static pages, not a dynamic one)
So, while on the client side "content/style" separation is enough, on
the server side this changes into "content-selection/style-selection"
separation.
There are two approaches for "content-selection": type 1 and type 2 (I'm
using the JSP terminology here, even if I dislike JSP as a technology).
Type 1 is basically "pull": you define what you want and you get it.
Type 2 is basically "push": the data is pushed into you and you just
make sure you present it.
an example of the first would be something like
<query>select * from blah</query>
and an example of the second would be something like
<ul>
#foreach $blah in $dataset {
<li>$blah.firstname | $blah.lastname</li>
}
</ul>
where $dataset is the container that holds the data passed to the template.
Type 1 approaches are normally called 'server pages' (examples are PHP,
ASP, JSP)
Type 2 approaches are normally called 'template engines' or 'templates
systems' (examples are Velocity, Jaxel, Jaxp)
Type 2 is also referred to as the "server-side MVC" where the "view" is
the template page, the model is the data that is passed to it and the
controller is the logic that creates that data.
Note how, for example, JSP can be used both in type 1 and type 2 and
frameworks like Struts enforce you to use JSP *only* in type 2.
Note that while I use XML in the above examples, nothing prevents you
from using different syntaxes and semantics for the two approaches, but
the "push vs. pull" mechanism is something that is critically different:
type 1 has the content-selection logic built in, type 2 does not.
Real life usage has shown that type 2 is better because presenation
concerns and content-selection concerns are normally very different.
What I am advocating is the need for keeping a "type 2" approach in
Longwell, which is already based on Velocity.
Now: velocity templates are "java oriented", which means that they don't
work on the semantics of RDF but thru the Jena API (which can be seen as
a DOM for RDF in a sense)
The question in my mind is: do we need a template language that is more
"natively RDF friendly"? or not?
If so, what does it mean? how do we separate selection operations
(iterations and conditionals) which belong to the template layer from
presentation information (block, inline, etc..) which belongs to the
style layer?
> + I'm really thinking about a more template-oriented language, where
> different templates/lenses are provides by different authors and the user
> can choose which templates or template combinations he likes to use for
> displaying an resource.
I've been involved in the cration of publishing system for a long time
and I've been part of the JSP working group, create the XSP
specification myself and witness the creation of basically every
server-side framework for java that exists and I'm very much concerned
that writing a template system for RDF in RDF means repeating the
"golden hammer" anti-pattern, which is: when you have a hammer in your
hands, everything looks like a nail (haystack for example, suffers from
this a great deal).
The use of RDF to describe an template for RDF seems overkill to me,
much like the use of XML to describe templates for XML ended up being
flawed (and since I was the proponent of that concept, I totally
understand where you are coming from!)
I agree that RDF might be perfect for presentational meta-metadata, but
for data-selection (which requires some scriptability) I have very
strong doubts.
But, as I said, I've been wrong many times in the past too, so I'm very
interested in hearing your opinions on this.
> + Ryan seams to think about something in between. His ideas about
> granularity are stylesheet-oriented. Having conditions and ordering by
> predicates is more template-oriented.
>
> This difference also explains why Ryan and I are approaching the problem
> from different sides in our vocabularies. In Ryan's vocab you start with
> ConfiguredClasses and use additional conditions to define the
> DisplayStyle/Part type of properties. In my vocab you start with a lens,
> which contains a number of parts/display styles and the properties are
> attached to these parts.
Makes sense. I had the same perception. Also, keep in mind that Longwell
is already using Velocity templates and therefore I think both Ryan and
I are oriented toward a presentational meta-metadata ontology because
Longwell served us well so far.
Note: even the SWAD-E portal implemented by the Jena team is using
Velocity templates and they reported similar happyness with the
approach. [of course, this doesn't mean it can't be improved, but it
does mean that it cannot be more complex than this or it won't be adopted]
> Now the interesting question is, which approach is:
> 1. more flexible
> 2. easier to use for authors
> 3. produces output that fulfils the expectations of the end users
> 4. better suited for distributed environments
>
> A first guess:
>
> 1. I think flexibility depends on the use case, but Ryan's cascading
> approach is definitively more elegant :-)
The declarative nature of presentational metadata is, in fact, the
beauty of CSS (which is not reflected in XSLT, being half-declerative
and half-procedural)
It also resulted in being a lot easier to understand for graphic designers.
> 2. I think it easier to write down directly what you want to have displayed
> in which order, than to use a cascading hierarchy of styles, that are
> combined afterwards. Proof: People easily understand HTML as a straight
> forward way to write down what should be displayed in which order. Much less
> use CSS really in a cascading way. Even less understand XSLT's recursive
> template mechanism (this is at least my experience with my Students here at
> the University).
Very true, but keep in mind that we might be talking about different
things: for content selection and templating, I agree that a procedural
approach is better, but for styling, I think that a purely declerative
approach is king. XHMTL+CSS shows this very very well. XSLT, in fact,
has nothing to do with style, but it's a tree transformation language
with first-class recursive tree querying capabilities and FO is an
utterly complex way to do XHTML+CSS without separation (which is why it
never took off).
> 3. If you expect the end uses to want something that looks and feels like a
> normal HTML-page, conditions and additional content are important. Using a
> template-oriented language it's easier to define sensible display
> blocks/views. If you don't have conditions you output explodes if you are
> having more instances or let's say more than 100 property values per
> resource (reasonable with foaf).
Agreed. But we already have that: velocity templates have iterations and
conditionals. Why do you see the need for something else?
> 4. I think it is easier to exchange/reuse display information if it is all
> included in an compact unit.
> So I can send somebody my foaf profile together with two proposals how to
> display it. He will decide if he uses them or prefers to use the display
> proposal of somebody else or a combination of both. This is more difficult
> if the display information is spread over a cascading hirarchy of style
> instances.
Well, this is like saying that having <font> in HTML is better than
having style moved into CSS because it's more explicit and easier to
move around.
I strongly disagree, if this is the case. And basically every web
designer on the planet disagrees too.
>>hold it! This is where I have a problem: I think you want a template
>>language for RDF in RDF.
>>
>>What I would like to have is a declarative visual ontology but
>>definately *NOT* a procedural template language since there are already
>>so many out there.
>
> Which? Can you please send me some links?
> The only RDF-data-model-based template language I know is Haystacks display
> ontology.
There are many template systems out there (see above) but none of the
ones I was thinking of treats RDF as a first-class citizen, but use an
object model provided by some APIs.
>>The fact is that foaf:person cannot be visualized because there is no
>>visual information (therefore, you cannot decide how to present this).
>>
>>You said "cascading RDF stylesheets" and that hits the nail on the head,
>>but when you say "you must also have the company logo", that freaks me
>
> out.
>
>>one thing is to have "content" in the CSS level (very useful in :before
>>and :after CSS selectors), because, for example, "Warning: " before a
>><warning>...</warning> element is style, not content.
>>
>>But a company logo, a header, a footer, they are al content, not style
>>and content should be dealt with a template language, not a stylesheet
>>language and I really think that writing a template language in RDF that
>>would be abstracted from the actual presentation markup would be
>>*waaaaay* abusive (and would reinvent half a dozen wheels)
>
> Why? Which wheels?
template languages' for one, either reinvent wheels or fall into the
same mistakes that took a decade to get uncovered for HTML and friends.
>>>11. Handling of Missing Values
>>>
>>>It should be possible to specify alternatives for missing values e.g.
>>>display foaf:firstname and foaf:last name if foaf:name is missing. Or
>>>display dc:title if rdfs:label is missing.
>>
>>Again, same thing: conditionals are not part of style because
>>conditionals are procedural not declarative.
>>
>>It is not up to the 'display ontology' to indicate "what" information
>>should be there, but "how" the information present should be displayed.
>
>
> I disagree here. If you are thinking of resources with lots of properties
> and lots of different types and lots of different vocabularies used for
> describing them, it is very reasonable to define what should be displayed in
> a certain situation. Otherwise you end up with exploding SVGs and long
> scroll-bars on your browser. Both not very user friendly. That's also the
> reason why I like Haystack's lenses a interactive filtering mechanism.
I did not say that those things are not important. I totally agree with
you that you need an abilityt to do "content-selection" on the server
side and the easier you can do it, the better.
What I'm questioning is the fact that we are thinking about "one"
ontology for both things, content selection and content presentation.
I think we need two different ones, at the very least.
>>Mixing these concerns is just like repeating the <font> HTML tag mistake
>>over again.
>>
>
> Brainstorming: Might it be an idea to have two different layers: One style
> layer and a separate filtering and ordering layer?
exactly ;-)
--
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 Sep 03 2004 - 15:32:39 EDT