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

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

Andrew Welch wrote:
>
> Interesting thread.... but it's not doing anything for the client
> side cause!
> 

I've been catching a lot of flack for betraying the REST cause of late,
too, over this same issue of media types (mostly)...  The architectural
style says that user agents rendering (text|application)/xml documents
with forms, css, javascript and such, is unnatural because the (t|a)/xml
media types say nothing about processing forms (or their associated
media types), or which methods are allowed to be used within forms
inside the media type (text/html only allows GET/POST as yet), or
anything about javascript DOM bindings, or the semantics of <h*> or
<ul><li></li></ul>, or rendering inline images, let alone describes the
use of any standard link relations or has any knowledge of <a> or
<link>'s relation to GET or how to process URI fragments.

I wouldn't bring up a nitpicky RESTafarian issue on this list, though.
But, the theoretical issue of how browsers should process media types
becomes very real when the issue of privilege escalation is considered.
The cause will be set back much more by hackers when they tell the
script kiddies how to compromise any (t|a)/xml XSLT-driven site they
find, and browser-resident XSLT becomes perceived as "insecure".

HTML functionality ought to require the use of HTML media types, before
browsers go and escalate privilege.  But, all I know I learned from
screwing up, so I could be wrong.  In fact, I hope I'm wrong, so I
brought this issue up with the TAG...

http://lists.w3.org/Archives/Public/www-tag/2010Jan/0013.html

...and put it rather bluntly.  If I'm mis-reading the intent that HTML
output requires an HTML media type, then I want to know, now.  I was
just watching this...

http://www.infoq.com/presentations/Systems-that-Never-Stop-Joe-Armstrong

...and posted to rest-discuss about how it applies to Web architecture.
I'm one of those who nods right along with Joe when he talks about how
making it work isn't what's important, making it right is what's
important.  I've been around long enough to have had client work last a
dozen years on the Web (without trying).  I expect my next effort at a
CMS to have a minimum lifespan of 20 years.  I'm planning on using
browser-resident XSLT to generate XHTML, so I'm more concerned about
what's the right way to do it, than I am about what works in today's
browsers.  I expect I'll be using client-side XSLT to generate HTML 5,
when the time comes -- I'll just link to a new XSLT stylesheet on the
client instead of rebuilding the whole system.

But I'm awful sure that any such system will come to require the use of
application/xhtml+xml or, in IE's case, javascript to call MSXSLT from
text/html.  If I'm right about this, I also want to know, now.  I was
only trying to help in the first place, not stir up a hornet's nest, by
presenting my thoughts on how best to support application/xhtml+xml
using content negotiation.

-Eric