- From: David Carlisle <davidc@nag.co.uk>
- Date: Sat, 28 Jul 2012 02:39:38 +0100
- To: public-xmlhypermedia@w3.org
On 28/07/2012 00:25, Rushforth, Peter wrote: > Javascript is the prevalent standard way to extend the functionality > of browsers nowadays, and if RESTfully applied, this is called > code-on-demand. It allows clients (ie browsers) which do not > understand a particular media type to be extended with code that > does. So, the understanding of a particular non-HTML media type > (most often json nowadays) does not need to be pre-programmed into > browsers I doubt json is the most common non-html media type handled by browsers. (css pdf png gif would all be more common I'd guess) also json parsing is (typically these days) directly programmed in to the browser to avoid security problems with using a full javascript parser on what is supposed to be a subset language. (JSON.parse() rather than eval()) Also as Liam noted javascript is only available if your host document is (x)html, it isn't available if you just serve some other xml type. so I don't understand the point you are making here at all. > As an XML web developer and user I want XSLT, or XQuery, (which > doesn't have pointy brackets and is therefore lacking ;-)), to be > usable on XML-based media types directly in the browser, in a way > that is simple Isn't that what <?xml-styleheet spec is for? How does anything discussed here help the XSLT case? > This might be accomplished if browsers used the @type to distinguish > css from xslt and thereby a) negotiate for the appropriate type and > b) delegate processing to the appropriate handler which is exactly the behaviour they do all implement for xml-stylesheet PI. David
Received on Saturday, 28 July 2012 01:40:00 UTC