Re: GRDDL and transformations (take 2) [#issue-whichlangs]

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