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

["Eric J. Bowman" <eric@xxxxxxxxxxxxxxxx>]

David Carlisle wrote:
> 
> > There is no such workaround in IE, that I know of, that doesn't
> > either break the "back" button or throw the browser into quirks
> > mode.
> 
> If I look at developer tools (F12) on, say, 
> 
> http://www.nag.co.uk/numeric/FL/nagdoc_fl22/xhtml/A02/a02aaf.xml
> 
> it appears to say it's being rendered using IE8 standards mode rather
> than quirks mode.
>

Yes, but I want one solution for IE 6+, which means doing the same
thing they've done on NAG -- skip the XML Prolog so it won't put IE6
into quirks mode.  Except I want the XML Prolog.  You can see the
problem for yourself by viewing that link in Opera, which assumes the
encoding to be utf-8, as you can see from the "Info" panel.  That's
hardly my only reason, though.

Forget I mentioned the back button issue, I couldn't find an example to
link to.

> 
> Incidentally, to get the mathml on that page to render you will need
> mathplayer, if you have mathplayer insalled you don't need xslt at all
> to render application/xhtml+mathml in IE as it acts as a mime filter
> and intercepts this mime type and displays (as html) in IE. You need
> to have mathml (doctype or namespace) somewhere at the top of the
> file just to trigger the filter) But the mathplayer mime filter isn't
> being used in the above page, which is simply using the
> xml-stylesheet PI.
> 

See, that makes sense to me as a REST developer -- serving application/
xhtml+mathml -- as it applies the self-descriptive messaging constraint.
What I'm trying to avoid is what I call "the w3schools approach" (which
the NAG site is an example of), which relies on shared misunderstanding
of Web architecture.  This has been quite the topic of late:

http://www.w3.org/2001/tag/group/track/actions/308
http://tools.ietf.org/html/draft-abarth-mime-sniff-03

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).

If I'm developing a Web system that utlimately presents the user with
HTML, then my media type selection will reflect this.  There can be no
misunderstanding that the payload is capable of executing scripts, and
I'm not exposing my system to XSS attacks relying upon the privilege
escalation inherent in XSLT apps which deliver HTML as text/xml.  So
until M$ gets their act together and implements application/xhtml+xml,
I must resort to using Javascript instead of an XML PI to call XSLT
transformations on IE.

Some accuse me of being a purist, but I say this is pragmatism.  Yes,
it's harder to follow correct Web architecture, but there are definite
consequences when one goes astray (encoding mismatches and privilege
escalation).  I'm glad there aren't very many such systems out there,
otherwise the importance of legacy support might outweigh the
importance of the Web's security architecture.  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.

-Eric