Re: Javascript and GRDDL [#issue-whichlangs]

Dan Connolly wrote:
> On Fri, 2007-03-02 at 17:55 -0800, Stefano Mazzocchi wrote:
> [...]
>> I've elaborated and commented more on my blog and added some
>> constructive criticism at the end.
>>
>> http://www.betaversion.org/~stefano/linotype/news/100/
> 
> "stop saying that GRDDL transformation can be defined in any language;
> it might be true in theory, but in practice is hardly useful if those
> transformations cannot respect the above three conditions;"
> 
> How is that different from what we already say?
> 
> "Transformations should have available representations in
> widely-supported formats. We expect most consumers to support XSLT
> version 1[XSLT1] for the foreseeable future, though XSLT2[XSLT2]
> deployment is increasing. While javascript, C, or any other programming
> language technically expresses the relevant information, XSLT is
> specifically designed to express XML to XML transformations and has some
> good safety characteristics."
>  -- http://www.w3.org/TR/grddl/#txforms
> 
> 
> I don't have strong feelings about this; we did discuss the possibility
> of limiting the options to just XSLT. And I generally think untested
> hooks are evil. The use cases for javascript haven't been fleshed
> out as much as we hoped. But what we've got in the spec seems fairly
> reasonable to me, and it's not clear that we really have more
> information now than when we made our decision.
> http://www.w3.org/2006/08/30-grddl-wg-minutes#item06

The item06 says:

 in sum: SHOULD support XSTL 1; MAY support others.

which is not what I read above. The paragraph above that DanC quotes is
very vague: not to be pedantic, but let's analyze the it a little:

"Transformations should have available representations in
widely-supported formats."

Well, d'uh! This is tautology. This is like saying "all URLs in this
document should be served by a computer that is turned on and has a
server listening on port 80 and a DNS entry that resolves that domain name".

"We expect most consumers to support XSLT version 1[XSLT1]"

we expect? I'm sorry, but for GRDDL to be of any use, it needs to
mandate something, even at the risk of being criticized for doing so.

If you say, "it should support one and may support others", you are left
with the option of someone implementing a GRDDL-aware agent *ONLY*
understanding, say, Javascript transformations and can happily claim
compliance, even if none of the basic test pages would work.

Don't you think there is something wrong if I can claim compliance and
not pass basic tests? What is the purpose of this spec if we move the
problem of understanding the data gleaning from the problem of
transformation execution portability? Have you really solved anything?

In sum, my suggestion is:

 1) rewrite the above paragraph to be clear and remove all possible
interpretation from implementors. State loud and clear stuff like SHOULD
or MUST or MAY, so that they know what to expect.

 2) turn *SHOULD* into *MUST* support XSLT1 (and say that it *MUST*
return RDF/XML or it *MUST* have a mechanism to indicate what type of
output the GRDDL-aware agent should expect, otherwise there is another
guessing step that needs to take place).

 3) state it clearly that it *MAY* support others, at the cost of
reducing portability.

Put yourself in my implementor's shoes: without something that GRDDL
mandates, it's impossible for me to implement something that would work
across all GRDDL-aware pages without me going some heuristic guessing
and/or user-driven configurations.

I'm fully aware that such guessing would happen no matter what (as such
as real life) but if the spec starts vague and flexible, it strongly
reduces the practical usefulness of this spec.

-- 
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 Sunday, 4 March 2007 19:36:03 UTC