GRDDL and transformations

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 themathematica
<http://www.iana.org/assignments/media-types/application/mathematica>ir
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[XSLT1]
<http://www.w3.org/2004/01/rdxh/spec#XSLT1> 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 implementationss 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 content-type for "application/xslt+xml"
quite yet [2], but we do have content types. 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.

Anyways, I feel quite solid about everything except the last paragraph
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
content-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 01:40:03 UTC