W3C home > Mailing lists > Public > public-xmlhypermedia@w3.org > August 2012

Re: Hypermedia & web architecture

From: David Carlisle <davidc@nag.co.uk>
Date: Thu, 02 Aug 2012 00:13:49 +0100
Message-ID: <5019B82D.6070205@nag.co.uk>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 August 2012 23:14:15 GMT