- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Mon, 19 May 2008 13:49:20 +0100
- To: Norman Gray <norman@astro.gla.ac.uk>
- CC: Harry Halpin <hhalpin@ibiblio.org>, Bijan Parsia <bparsia@cs.man.ac.uk>, public-grddl-comments@w3.org, Alan Ruttenberg <alanruttenberg@gmail.com>
Very cute. & I think and hope that my implementation would retrieve the XSLT version. However, it may have the unfortunate side effect of upping the appararent normativity of the XSLT - in that there would be at least one URL that could retrieve either the XSLT or the normative spec. Jeremy Norman Gray wrote: > > Greetings, > > On 2008 May 16, at 17:52, Harry Halpin wrote: > >> I think the central question is whether or not at this point the GRDDL >> WG recommends that at least one GRDDL transform point to either: >> >> 1) A non-executable list of implementations >> 2) An executable transform, likely an XSLT one. >> >> One could of course have *two* GRDDL transforms, one that points to 1) >> and one that points to 2), but we are not sure how 1) would behave >> with current GRDDL transforms. > > An apparently obvious solution here is to suggest that the > transformation be retrieved using content-negotiation, so that > dereferencing the GRDDL transform produces different documents depending > on whether the request accept header included one or more of > application/xslt+xml, application/x-javascript?, text/html, or even > application/rdf+xml, with the last one potentially giving a > machine-readable list of available transformers and their properties (of > course, that machine-readable spec could be encoded within the text/html > version using GRDDL or RDFa, but this verges on the confusing...) > > That way, if there's no XSLT transform available for a document, then > the origin server returns 406 Not Acceptable, and if there's more than > one transformer implementation, in different languages, it could > potentially return 300 Multiple Choices (that's not realistically > supported in browsers, but could be in a GRDDL library). > > The example in the spec includes the XSLT transformation being retrieved > with an accept:application/xml header, which is rather generic. > > This seems so obvious that I'm sure I'm missing something, but the only > mention of content-negotiation in the GRDDL spec is in the context of > namespace documents, and there's no mention of MIME types at all, except > rather in passing in the example. > > Best wishes, > > Norman > >
Received on Monday, 19 May 2008 12:50:14 UTC