- From: David Carlisle <davidc@nag.co.uk>
- Date: Thu, 02 Aug 2012 00:13:49 +0100
- To: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
- CC: "public-xmlhypermedia@w3.org" <public-xmlhypermedia@w3.org>
On 01/08/2012 23:04, Rushforth, Peter wrote: > Hi David, > >> You can serve an html document that contains (say) ChemML as inert >> markup in one script element and some javascript in another script >> element that parses it and processes it in some way but the host >> document (and thus the mime type of the thing) has to be text/html >> even if it just consists of the xml markup of chemML and a script >> element to process it. > > What is special about the script element, and why does the content > have to be _inside_ the element ie why can't the content be > referenced by the href and type attributes? Almost everything about the script element is special:-) You need an html (or xhtml or svg) script element to trigger javascript. If you want the non-html code (say chemmml or some other xml format) to be in the same file then the most reliable way (from html) is to put it in a script element with any non-javascript type specified. That way the data is not parsed as xml and works pretty much the same as a CDATA section in XML. Then the content of that element can be picked up by javascript and parsed using the xml parser. An alternative as you say is to fetch the data via second http request, but you still need an initial html file to start the process. If you use xhtml rather than html as the controlling document things are different of course as you can embed the foreign XML and it will be correctly parsed as XML without needing to protect it in a script element. > >> If you want that interaction to be controlled by javascript then >> the controlling media type has to be one of the ones for which >> browsers implement script processing, so html, basically. > > If browsers contain full xml parsers, then a lot of that seems to be > a waste of effort if the controlling media type hast to be html. But > anyway, I'm not trying to say browsers should work differently, > because I guess if one wants browsers to work differently, one can > always join a project and try to make that happen. I'm just trying > to figure out *why* the contolling media type has to be html. xhtml would do as well as noted above, but it can't be docbook (say). The alternative, which we've been doing with mathml since last century is to serve with (any) xml mime type text/xml application/xml application/xhtml+xml, doesn't really matter which) and then use an xml-stylesheet PI. the xslt stylesheet triggered can generate html/javascript/mathml/css anything else the browser understands. > >> >>> Isn't that what <?xml-styleheet spec is for? How does anything >>> discussed here help the XSLT case? which is exactly the >>> behaviour they do all implement for xml-stylesheet PI. >> >> Why is a processing instruction necessary? > >> You suggested a <link> element but <link> is _HTML_ It would have >> been wrong for an XML stylesheet spec to pre-allocate an element >> name link > > Not sure why a link element in html is any more wrong than specifying > a processing instruction. Nothing wrong with a link element in _html_. I thought you were suggesting a link element in arbitrary xml. The xml-stylesheet PI applies to _any_ XML. docbook, TEI, some xml you just made up, can all be rendered in browser using that technique to specify styling. > >>> And, can I run an XSLT 2 stylesheet with that facility? > >> Indirectly yes, see saxon-ce (internally it uses an xslt 1 >> stylesheet loaded by the browser which just loads a stub html >> document with a script element that loads the (javasript >> implementation of) the XSLT2 engine. > > And how does the XSLT processor load resources off the web then? For > example xsl:import, xsl:include etc? Not sure what you mean by "how" it works although there are various browser restrictions on _where_ you can fetch resources from relative to the initial document's origin. > > Thanks, Peter > David
Received on Wednesday, 1 August 2012 23:14:15 UTC