Re: [xsl] Modern web site design with XML and XSLT

Subject: Re: [xsl] Modern web site design with XML and XSLT
From: "Eric J. Bowman" <eric@xxxxxxxxxxxxxxxx>
Date: Tue, 5 Jan 2010 15:16:42 -0700
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

Current Thread