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

Re: Comments on GRDDL

From: Andrew Eisenberg <andrew.eisenberg@us.ibm.com>
Date: Wed, 2 May 2007 11:42:57 -0400
To: Dan Connolly <connolly@w3.org>
Cc: public-grddl-comments@w3.org, w3c-xsl-query@w3.org
Message-ID: <OFCF84E678.0A33E373-ON852572CF.005418AF-852572CF.005658A0@us.ibm.com>
w3c-xsl-query-request@w3.org wrote on 04/30/2007 11:36:28 AM:

> > 1) When a transformation fails, or it produces non-RDF elements, the
> > result/meaning should be specified. 
> Without any argument as to why the specification should be
> elaborated this way, it's difficult for me to take your comment
> up with the GRDDL WG.
> We're happy to look at details of any examples or scenarios
> where this failure would be a threat to interoperability.
> It seems more likely that the results of our investigation
> would go into our test cases document than into the specification.
>  http://www.w3.org/TR/grddl-tests/
> The specification of a GRDDL result is written declaratively.
> To say that a transformation fails is like saying that adding 4 and 7
> fails. Yes, a machine that's doing the computation might
> fail, but the meaning of the expression 4+7 remains what it is.

The failure of a transformation could be interpreted by a processor as 
producing no RDF data (fail silently) or the error could be passed back to 
the invoker.

On producing non-RDF elements, let me extend your analogy and say that a 
processor returns both 11 and "volunteer". The extraneous value could be 
silently ignored, or the entire answer could be considered meaningless and 
the invoker informed of the error.

We are suggesting that both cases be acknowledged in the specification, 
and that you specify the behavior allowed by a GRDDL processor.

                                                -- Andrew
Received on Wednesday, 2 May 2007 15:43:17 UTC

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