- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Tue, 29 Aug 2006 21:45:36 +0200
- To: "Dan Connolly" <connolly@w3.org>
- Cc: "Harry Halpin" <hhalpin@ibiblio.org>, public-grddl-wg <public-grddl-wg@w3.org>
On 8/25/06, Dan Connolly <connolly@w3.org> wrote: > to reiterate: my position on issue-whichlangs is > GRDDL clients SHOULD support XSLT 1.0 > GRDDL clients MAY support other programming languages. +1 The former because at this point in time that's what we've got, it offers the best chance for interop, and there's still the option for not supporting XSLT if there's a good reason not to (as a bonus it takes the edge off "what do we mean by support"). The latter because we don't know what the future holds ;-) There's one aspect I don't think is significant, but is still bugging me. Only read the following if you're short of something to do. I've not even thought it through enough to describe properly. The transformation is currently described as a functional algorithm. Seems like a named GRDDL transformation will in this way just specify the mapping, irrespective of any transformer implementation. But by implication, is the current definition overly coupled to the processing model? Is there "how" in with the "what"? My guess would be it shouldn't really matter, any suitable algorithms or mappings being isomorphic. But maybe there are cases where it could become an issue. In the extreme (but conceivably common) case, a non-RDF doc might already have been transformed, the RDF/XML being cached (heh, like <link rel="alternate"... on the same URI), the transformation effectively be implemented as a lookup. But what about if there was a long doc and a timeout on the processor, so in certain circumstances only a subset of the full graph was produced - the function has another input, time. Partial fulfilment of the request could well be useful, but strictly speaking is unacceptable. My concerns may be off the mark, or just totally irrational, but something makes me itch with the idea of the XSLT processor (or Javascript interpreter, whatever) being implicit in the chain. Cheers, Danny. -- http://dannyayers.com
Received on Tuesday, 29 August 2006 19:45:52 UTC