GRDDL and transformations (take 2)

Somehow it appears this e-mail didn't come through the first, time - so
again - here's my take on "minimum set of transformation formats that
must be supported by GRDDL processors" - I'm also running this by Liam
and Henry since I'd be interested in their input as well.

Currently the GRDDL document says: "The transformation link type refers
to a transformation algorithm that should have a available
representations in widely-supported formats. We expect most consumers to
support XSLT version 1 for the foreseeable future...While javascript, C,
or any other programming language technically expresses the relevant
information, XSLT is specifically designed to express XML to XML
transformations and has some good safety characteristics."

So, if I were implementing GRDDL, what transformations *must* I
implement, if any, and what transformations should I implement?
 
My feeling is that the URI of the transformation link can return in
principle *anything*. However, since GRDDL is for client side
processing, the only two languages that almost all browsers support is
XSLT and Javascript. Should we forbid other types of transformations? If
we do, we guarantee interoperability by giving the implementers less
freedom, but if we may also restrict the types of transformations and
uses of GRDDL. I'm tempted by the side of more freedom.

So, I'd say "A GRDDL implementation MUST support XSLT 1.0, and a GRDDL
implementation MAY support other transformations."

Not sure: Do people think GRDDL "MUST support ECMAscript[1]" I mean, I
think it makes sense, as most GRDDL implementations should be able to
call javascript easily enough - what do people think?"

A GRDDL implementation MUST use the content type of the transformation
to determine the what the transformation is."

Although we have "application/ecmascript" and "application/javascript",
it appears that there isn't a media type for "application/xslt+xml"
quite yet [2]...

To get around this, we could say:

"If the transformation does not specify a content-type of a
transformation language the GRDDL implementation understands, then the
GRDDL implementation SHOULD assume the transformation language is XSLT 1.0"

This leads to some interesting GRDDL designs, because I think it allows
us to fulfill some of the needs people have rather mentioned (albeit
without detailed use-cases), without changing anything about GRDDL.

These are all "edge-cases" (mostly from Liam and BenA) which I think are
likely out-of-scope, but I do think the content-type method handles them
if people really want to do them. For example, if someone wanted a
pipeline of transformations, then they would just have a transformation
link to a soon-to-exist XMLProc and its might-exist media-type[4]. If
someone wanted to not do a client-side transform, but just to return
static RDF, then they could link to RDF file of media type
'application/rdf+xml', and the GRDDL could just do nothing to the HTML
and return the RDF file. One could then pass arguments via the
transformation in the URI as normal, like
"http://www.example.org/myws?arg1=x&arg2=y". In fact, this could be a
server-side RESTful web service that returns vanilla RDF.

I feel this is a good choice  since it does not change the current GRDDL
spec or implementations at all, but merely clarifies things, but I'm
just showing us where using media types leads us.


    cheers,
         harry

[1]http://www.ecma-international.org/publications/standards/Ecma-262.htm
[2]http://www.iana.org/assignments/
[3]http://www.ietf.org/rfc/rfc4329.txt
[4]http://www.w3.org/XML/Processing/


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Friday, 25 August 2006 02:13:02 UTC