Re: Javascript and GRDDL [#issue-whichlangs]

On Sun, 4 Mar 2007, Stefano Mazzocchi wrote:
> Dan Connolly wrote:
>> On Fri, 2007-03-02 at 17:55 -0800, Stefano Mazzocchi wrote:
>> [...]
>>
>> 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

Yes, 'evil' being the operative word here.

>> The use cases for javascript haven't been fleshed
>> out as much as we hoped.

Judging from [ http://www.w3.org/2006/08/30-grddl-wg-minutes#item06 ] 
(where the issue was resolved), the decision to say something 
explicit about the technical feasibility of other langugaes is the hook 
you are talking about here.

But this hook isn't mentioned in any of the 
normative portions and in addition, the informative rules (as 
they are now written) are declarative, in that they only say 
what SHOULD happen if a specific scenario occurs and the only scenario the 
rules cover is XSLT which outputs RDF/XML.

> 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.

Well, yes the open-ended  wording might work against the normative 
sections that are explicit about behavior, but what GRDDL *does* mandate is that in 
order for a piece of software to be a 'GRDDL-aware agent' it *has* to generate GRDDL results and 
it describes the *only* means by which GRDDL results can be created: XML 
in, XSLT processing, RDF/XML out.

> 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.

It couldn't claim compliance because it wouldn't have generated GRDDL 
results in the ways outlined.  The current wording is exclusive of 
non-XSLT-to-RDF/XML only in the case where those are the only transforms 
used.  It is basically the difference between IF and IFF.

I.e.  A => B  or  A <=> B

A specification doesn't necessarily have to be explicitely exclusive 
to mandate behavior.

> Don't you think there is something wrong if I can claim compliance and
> not pass basic tests?

See above

> 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?

You've 'solved' the XML to RDF/XML via XSLT scenario, at the very least.

> 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).

All of the above is already said by in the normative sections and 
by interpretation of the informative rules (though the preceding section 
may indeed not say the same thing and be the cause of confusion). 
The only part missing (not mentioned anywhere) is a mechanism to indicate 
the format of the output (assuming RDF/XML wasn't the only output 
*expected*) - I believe this has been suggested before as XSLT itself does 
provide such a mechanism: xsl:output/@media-type

> 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.

See above about what *is* mandated declaratively with IF (one-way 
implication) rules and correponding normative, human-readable text:

1. XML in
2. XSLT1 processing
3. RDF/XML out

Chimezie Ogbuji
Lead Systems Analyst
Thoracic and Cardiovascular Surgery
Cleveland Clinic Foundation
9500 Euclid Avenue/ W26
Cleveland, Ohio 44195
Office: (216)444-8593
ogbujic@ccf.org

Received on Tuesday, 6 March 2007 00:25:52 UTC