- From: Harry Halpin <hhalpin@ibiblio.org>
- Date: Fri, 25 Aug 2006 02:39:45 +0100
- To: public-grddl-wg <public-grddl-wg@w3.org>, Liam Quin <liam@w3.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>
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