David Carlisle wrote:
Not at all. It is an example of following w3c standards to the letter.
It's an example of browsers using content-sniffing to override the
server-defined media type. As RFC 3023 explains, text/xml is for:
"
If an XML document -- that is, the unprocessed, source XML document
-- is readable by casual users, text/xml is preferable to
application/xml...
Application/xml is preferable when the XML MIME entity is unreadable
by casual users.
"
A server sending text/xml is expressing an intent that the payload not
be processed and displayed to casual users. A browser that processes
XML PIs anyway, is overriding server intent. I cannot get any browser
to apply a CSS XML PI to content served as text/xml, with the XSLT PI
commented out. So, browsers have emulated the featurebug in IE 6 in
their own XSLT implementations... but they're all sniffing content for
a very specific type of XML PI to process, and escalating that text/xml
content to text/html privilege the second they allow scripts to execute.
There is nothing about the 'text/xml' media type which can be
construed as telling browsers anything about how to process that
payload. Without an XSLT PI, some browsers will display an XML file
as a collapsible tree, like IE does. Other browsers will display
the output, ignoring all tags and CSS XML PIs (unless
application/xml is used). What no browser should do, is treat that
as text/html and allow it to execute scripts -- that would be
"privilege escalation" as described in my links -- until you put in
an XSLT PI (for some reason).
That was the main point of developing XML, to allow XML to be served
over the web, and have styling information being supplied by a
referenced stylesheet. If you don't suppy a style then you et a
browser specific default, but since a style is supplied that is not
relevant here.
It was never the intent of the text/xml media type to actually process
any XML PIs, and aside from XSLT PIs, browsers don't.
The point being, will an architecture using the w3schools approach
still function in new browsers in two years? Five? I don't have
that concern if I'm conforming with native Web architecture.
I fear you are misunderstanding the relevant specifications.
Obviously if browsers stop supporting xslt or the xml-stylesheet
within the next 5 years things will stop working, but otherwise this
is a fully standards conforming site (as is the xhtml version of the
MathML2 Rec at http://www.w3.org/TR/MathML2/overview.xml which uses
similar technology)
Browsers won't stop supporting XSLT or XML PIs any time soon, what they
may very well stop doing, is sniffing around in text/xml content for
XSLT PIs, processing same, and rendering the results as if the server
had sent it text/html, including the execution of scripts.
Given that your suggested alternative appears to involve gratuitously
invalid xhtml and, you report, fails to work, I can't take too
seriously your comments that using xslt in this way breaks web
architecture.
You should take my arguments seriously, as they are being presented in
terms of the relevant standards. My XHTML 1.1 pages validate just
fine, thank you, both before and after transformation -- where did I
say it didn't work? If my XSLT output isn't well-formed, browsers
report an error because they're in application/xhtml+xml mode, not
text/html mode, either standards or quirks, to render output. If your
browser-resident XSLT output isn't well-formed, do browsers quit on the
error?
-Eric
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--