- 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