W3C home > Mailing lists > Public > www-tag@w3.org > January 2010

Re: ACTION-308 (part 2) Updates to 'The Self-Describing Web'

From: David Carlisle <davidc@nag.co.uk>
Date: Fri, 8 Jan 2010 09:44:16 GMT
Message-Id: <201001080944.o089iGtt006136@glenlivet.nag.co.uk>
To: "Eric J. Bowman" <eric@bisonsystems.net>
CC: www-tag@w3.org

> Until recently, the Web had worked this way for a long time, which
> reinforced my interpretation of RFC 3023 as saying that text/xml isn't
> scriptable, if you need to execute scripts for the user, go with
> application/xml.

All browsers that have supported xml-stylesheet have supported it in the
text/xml media type since the beginning, so I don't know what you mean by

For example


which dates from 2002 worked at the time in IE [5.5], netscape [6],
mozilla and amaya, and obviously has worked in every version of firefox
that's been released since then which is derived from the mozilla base.

> I see that as sniffing, unless the media type is application/xml.

I don't believe there is any reason to see this as sniffing, or expect
text/xml or application/xml to differ here. The only reason for
preferring application/xml over text/xml is a clearer story re character

> I'm just a guy who had gotten used to using text/xml for files I
> intended to be opened in an editor, or displayed raw.  Without xml-
> stylesheet PIs, IE displays text/xml as a collapsible tree.  Other
> browsers used to just treat all elements as unknown in-line, while
> others displayed it as plain text.  Aside from one aberrant browser, no
> user-agent would ever have reason to start executing scripts.  Or so I
> thought, anyway.

For a long time, other browsers, eg firefox, opera etc have followed
IE's lead in applying a default stylesheet to text/xml files to display
a "syntax-highlighted" version of the file if no xml-stylesheet provides
an explict style. This is different to the behaviour if the same file is
served as text/plain.

> What I do not expect to see when I dereference a text/xml URL with a
> browser, is an HTML page where tables, forms, links and Javascript
> work.

If the xml file has an xml-stylesheet processing instruction referencing
a stylesheet that generates html or xhtml, that is exactly what you
should see. Being able to style xml in this way is after all the whole
point of having an xml-stylesheet recommendation.

> HTML doesn't list text/xml as an allowed media type.  The text/xml
> media type says nothing about processing tables, forms, links or
> javascript DOM bindings. 

Nor should they. The text/xml (or application/xml) media type
describes the document that is being served. the text/html media type
describes (in this case) the document that is being rendered which is
the result of a transformation triggered by the initial xml file but may
include (via document()) any number of other sources as well.

> I use application/xhtml+xml (with xml-stylesheet PI to call XSLT) or
> text/html (with Javascript to call XSLT) as media types, when I'm
> ultimately providing an XHTML interface to the user.

If the document being served is not xhtml then it is wrong to serve it
using the application/xhtml+xml media type. The fact that some
applications supporting the xml-stylesheet recommendation may transform
the document into xhtml and some (such as wget) will not, should have no
bearing on the media type to be used for the source document.

Received on Friday, 8 January 2010 09:45:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:32 UTC