W3C home > Mailing lists > Public > public-grddl-comments@w3.org > April to June 2007

Re: Javascript and GRDDL [#issue-whichlangs]

From: Stefano Mazzocchi <stefanom@MIT.EDU>
Date: Wed, 25 Apr 2007 10:38:44 -0700
Message-ID: <462F9224.9080706@mit.edu>
To: Harry Halpin <hhalpin@ibiblio.org>
CC: public-grddl-comments@w3.org

Harry Halpin wrote:
> Stefano,
>     While it's been a while, we have still kept your comments as
> regarding "should/must" in supprot of XSLT1.0 in mind regarding GRDDL.
> Stefano Mazzocchi wrote:
>> Chimezie,
>> thanks for your feedback and thanks for the WG for being willing to
>> consider my feedback.
>> As for which-langs issue, I continue to be slightly dissatisfied with
>> the "should support XSLT1, may support others" resolution as I think
>> that a "must support XSLT, may support others" (version should not be
>> specified as XSLT has internal version control semantics) would be
>> preferable at least for a baseline compatibility.
> To review, in the primer we have the words [1]:
> "Generally, if the transformation can be fully expressed in XSLT 1.0
> then it is preferable to use that format since GRDDL processors should
> be capable of interpreting an XSLT 1.0 document."
> Note that as regards the specification [2], we initially decided not to
> use conformance labels [3] but then in light of security concerns
> decided to use conformance labels in the specification only to define a
> GRDDL-aware agent, but do provide the following strong wording regards
> XSLT 1.0:
> "XSLT version 1 is the format most widely supported by GRDDL-aware
> agents as of this writing, though though XSLT2  deployment is
> increasing. While technically Javascript, C, or virtually any other
> programming language may be used to express transformations for GRDDL,
> XSLT is specifically designed to express XML to XML transformations and
> has some good safety characteristics."
> We believe that this wording makes it very clear that XSLT 1.0 should be
> supported by GRDDL-aware agents. However, in the light of Web
> technologies (for example, Ben Adida's hGRDDL, which does not wish to
> support XSLT 1.0 [4]), the general opinion as I have been able to gather
> in the WG is that tying GRDDL with a "must" conformance label to XSLT
> 1.0 would be be premature. Does this reasoning and the strong wording in
> the Primer and Spec satisfy you, given the constraint the the GRDDL WG
> has at least one GRDDL developer that does not wish to support XSLT 1.0?

I'm a little puzzled by your reasoning.

Ben wants to use javascript and avoid XSLT. So do I. So will a lot of
people. So we are in total agreement that GRDDL agents should not be
exclusively tied to XSLT.

But it has also be made clear that, at least at this point, it is
premature for the GRDDL WG to specify how javascript GRDDL should be
have. I agree with that, meaning that Ben and I should not be stopped in
their research and innovation around this important aspect of data
gathering bootstrapping.

That said, if GRDDL-agent A supports javascript only and GRDDL-agent B
supports XSLT only, what would a GRDDL-compliant claim mean to the poor
soul that simply wants to get some data out of a web page?

Truth be told, since with GRDDL it's the web sites that drive the dance,
not GRDDL agents (well, unless we have GRDDL-wrapping greasemonkey
scripts, but that's hardly any different than scraping in my book), it
doesn't really matter what the spec says, but it matters what GRDDL
"flavor" the web site is going to provide you (if any, obviously).

> Of course, it is the ultimately use and the market that will decide
> whether GRDDL aware-agents that do not support XSLT 1.0 will succeed or
> not.


But, there is a possible world in which the spec *mandates* that a
baseline XSLT flavor needs to be present in order for the web site to
claim GRDDL compliance, and another in which the spec *suggests* that
but really doesn't want to get in the way of those who want to make it
easier for people to get their data in a more structured form.

The first situation might make it harder on the web sites and easier on
the GRDDL agent developers. The second the other way around at the
expense of creating a world where there are several, incompatible, GRDDL
flavors. Sort of an RSS-like situation if you wish: all doing the same
thing, but not exactly the same way.

Which one is better? which one will have a better chance of taking off?
or does it matter at all what the spec says?

I candidly admit I have no idea what the right answer is to these
questions, so I won't try to influence it any further.

It does seem weird, looking at this with the eyes of somebody that will
probably have to implement a GRDDL agent, to have a spec that doesn't
really help me.... but it is also true that specs, alone, rarely have
all the info that is used to implement something, yet that doesn't
prevent the technology to be widely useful (HTML anyone?)

So, at the very end, I remove my dissatisfaction and agree with the WG's
line of thinking to make it easier for web sites to adopt GRDDL than to
make it easier for GRDDL agent developers to do something with it,
because that's more socio-economically sound in a bootstrapping situation.

> [1]http://www.w3.org/2001/sw/grddl-wg/doc29/primer.html
> [2]http://www.w3.org/2004/01/rdxh/spec
> [3][2]http://www.w3.org/2004/01/rdxh/spec#issue-conformance-labels
> [4] http://www.w3.org/2006/07/SWD/wiki/hGRDDL_Example


Stefano Mazzocchi
Digital Libraries Research Group                 Research Scientist
Massachusetts Institute of Technology
E25-131, 77 Massachusetts Ave               skype: stefanomazzocchi
Cambridge, MA  02139-4307, USA         email: stefanom at mit . edu
Received on Wednesday, 25 April 2007 17:39:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:52:28 UTC