RE: GRDDL (was: RE: Extensibility strategies)

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Toby A Inkster
> Sent: Tuesday, August 05, 2008 7:08 PM
> To: Justin James
> Cc: public-html@w3.org
> Subject: Re: GRDDL (was: RE: Extensibility strategies)
> 
> 
> On 5 Aug 2008, at 20:22, Justin James wrote:
> 
> > * It is highly complex - Look at the diagrams on that page...
> > anything that
> > requires that many transformations and steps is prone to failure and
> > problems. One misbehaving parser in that chain breaks it.
> 
> Misbehaving rendering engines have been a major annoyance for authors
> for ages, but people still use CSS. GRDDL is very much simpler than
> CSS. (Though GRDDL makes use of XSLT which is quite complex -
> however, many browsers do already have reasonably good XSLT
> implementations.)

My concern is that the length of the dependency chain on GRDDL looks rather
long; more potential points of failure relying upon parsers of some fairly
complex items. I just don't feel comfortable with it.

> > * Confusing - Maybe the spec is still a draft, but I am a smart guy
> > and it
> > took way too long for me to "get" this document. Even worse, it
> > relies upon
> > having an in-depth understanding of another obscure spec, RDF
> > (another one I
> > never heard of until a few days ago).
> 
> RDF is the thousand-pound gorilla of the metadata world. There is
> virtually no work going on in the online metadata world that does not
> somehow involve RDF. If GRDDL couldn't output RDF, then it would be
> destined to be no more than a plaything. Any solution that aims to do
> for semantics what CSS has done for style would *have* to use RDF to
> be taken seriously.

>From what I can tell about RDF, I agree. But I don't think that the RDF
syntax is necessarily something that many HTML authors can really work with.
My preference would be a simplified, lightweight syntax that cleanly
maps/translates/transforms to RDF.

> The same with RDF. The high level view is dead easy:
> 
> 	subject1 predicate1 object1 .
> 	subject2 predicate2 object2 .

I think the documentation needs to be improved significantly, because this
was *not* obvious. Actually, that's not entirely true. I could follow the
"RDF Primer" until Section 2.2, when it suddenly stopped being clear to "Joe
Six Pack".

> And then you just need to know that subjects and predicates are
> normally expressed as URIs. Objects are sometimes URIs, sometimes
> literals.
> 
> e.g.
> 	<http://dbpedia.org/resource/Sky>
> 	  <http://example.com/ns#colour>
> 	    "blue" .
> 
> Of course, the deeper you look, the more complicated it gets, with
> BNodes, and multiple serialisations (Just as HTML5 has different
> representations - HTML, XHTML and DOM - so does RDF have various
> different representations, in XML, a text-like format, JSON, etc.),
> reification, datatypes, CURIEs and so on.
> 
> But the same can be said of CSS - the deeper you look, the more
> complicated it gets. Gurus are well-versed in browser-specific hacks,
> the rules of the cascade, inheritance, default values of properties
> for different elements, media queries, browser-specific extensions,
> etc.

The "RDF Primer" reached that level barely a few sentences past the
introduction, Section 2.2 to be exact. CSS never reaches that level for
anyone who does not need a "guru" level of knowledge. I made do for YEARS
with CSS just knowing the basic inheritance model, and muddling through
figuring out what worked well across all browsers (to this day, I reject
browser-specific hacks). Most HTML authors don't need to know that much
about CSS to do their jobs.

> But at it's heart, the concept of triples, with most of the
> components being URIs, RDF is actually pretty simple.

I can see that, but the documentation is not very helpful in showing how
simple it actually is.

> > * HTML abuse - This seems to be predicated on abusing and mis-using
> > HTML.
> > Maybe I am reading it wrong.
> 
> Not sure why you think that. GRDDL has two main methods of linking to
> a transformation from an HTML file. The first is very much like CSS...
> 
> 	To link to a stylesheet, you use:
> 	<link rel="stylesheet" href="style.css">
> 
> 	To link to a "semantics sheet", you use:
> 	<link rel="transformation" href="semantics.xslt">
> 
> The other uses the HTML <head profile> attribute. Rather than linking
> to the XSLT file directly, you include the URI for a profile document
> in your <head profile>, and then the profile document links to the
> XSLT file. This second method of linking is intended to be not so
> much used for ad-hoc linking to "semantics sheets" like the first
> syntax is, but rather for linking to the profiles of Microformats
> (official ones or otherwise).

I see the source of my misunderstanding now, thank you! The problem is that
I did not see at all how that worked, so it looked like something abusive to
the HTML itself was occurring.

> GRDDL is quite simple and elegant, except for the fact that is
> specifies that the data transformations must be written in XSLT,
> which is not very elegant in syntax, not is it an especially well-
> known programming language amongst most web authors. I think
> Javascript may have been a better route for them to follow, but I
> suppose that ship has sailed.

Unless you spent a lot of time writing Lisp, C, or Perl, "elegance" and
"simplicity" most do *not* go hand-in-hand. Not a dig at those languages in
the slightest (I loved Perl for years, and to this day I want to find a good
reason to be working in Lisp). But as others have pointed out in a different
thread, indirection leads to confusion. And in this case, the "elegance" of
GRDDL is based upon its acting as a translation system to an intensely
complex system of indirection (RDF) which in turn gets parsed and
transformed to any number of undefined systems (via XSLT). While that may be
"elegant" in that it successfully leverages so many other technologies that
the actual GRDDL spec is quite short considering what it does, it means that
not only is the technology itself indirect, but learning it is as well.
Trying to make sense of GRDDL was like trying to find the bottom of an
iceberg, I kept finding more and more below the surface without ever getting
to my goal.

The more I read and re-read the GRDDL and RDF information, it becomes clear
what the real problem is. The problem is *not only* the technology, it is
the documentation. The phrase from "Beetlejuice" comes to mind: "This reads
like stereo instructions." I've now invested nearly an hour of my time with
the various primers, specifications, and so on. The specifications are
squarely aimed at people implementing consumers of GRDDL and RDF (like
browser vendors). The "primers" have low usability; you brief comments here
helped me understand both of these items much more than the "primers". That
is a bad sign.

I am not sure if you are involved with either the GRDDL or the RDF groups,
but I would definitely suggest that they have someone who is completely
ignorant about either of those specs sit down with the documentation and
trying to write an HTML document that really uses those two technologies,
and basically perform a Jakob Neilsen-style "listening lab" to find out
where that documentation is broken and needs to be fixed. To summarize,
unless that documentation makes sense (and not just to someone in the XML
elite, but a typical developer), your adoption rate is going to be close to
0%.

At the end of the day, I think that GRDDL has a lot of promise. But I think
that anything that will gain any traction in the HTML community, outside of
the really elite XML folks out there, is going to be a lot simpler than
GRDDL, even if it is not as elegant. I think that the best solution is
really going to be something that has a pre-defined set of semantic meanings
and lets people attach them in a selector/class system like CSS. Preferably,
it should have identical syntax to CSS, so no one needs to learn anything
new.

J.Ja

Received on Wednesday, 6 August 2008 04:32:16 UTC