[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Modern web site design with XML and XSLT

Subject: Re: Modern web site design with XML and XSLT
From: "Eric J. Bowman" <eric@xxxxxxxxxxxxxxxx>
Date: Wed, 6 Jan 2010 09:53:25 -0700
Re:  Modern web site design with XML and XSLT
David Carlisle wrote:
> 
> > But I'm awful sure that any such system will come to require the
> > use of application/xhtml+xml...
> 
> The role of xslt (whether in the browser or on the server) is to take
> arbitrary xml (or potentially with xslt2, text,) and convert it into
> (x)html to render in the browser.
> 

No, on the server an XSLT output processor creates a document.  In a
browser, an XSLT output processor directly manipulates the DOM generated
by the browsing context (by which I mean, application/xhtml+xml sets an
XML browsing context, other media types set an HTML browsing context
-- HTML has standards and quirks mode, XML only has standards mode)
which called the transformation.

>
> It makes absolutely no sense to say that the _source_ files for that
> transformation should be served using an html mime type. They may be
> "almost" xhtml but they may be docbook or some random xml that has
> just been made up. The point of the xml-stylesheet PI is to allow
> such documents to be styled and rendered in the browser.
> 

I disagree.  I use xml-stylesheet PIs to control server-side
transformations, too.  My Atom content contains internal control data,
so that content has XSLT PIs which the backend ignores, but the front-
end executes an identity template which suppresses the XSLT PI and the
internal control data; external users don't see any XML PI or internal
system data.

When dereferencing an URL which sends XML content containing XML PIs,
it's this source document which sets the browsing context.  Its media
type is the authoritative metadata as per:

http://www.w3.org/2001/tag/doc/mime-respect

"
For Web architecture, a design choice has been made that metadata
received in an encapsulating container MUST be considered authoritative
and used in preference to metadata found by inspection of the data,
declared by embedded metadata, or provided by external reference.
"

> 
> whether the browser renders this as html or xhtml or plain text is a
> function of what is generated by the stylesheet (and its specified
> output type).
> 

The output type specified in an XSLT document is irrelevant in
browsers.  If it were obeyed, this would be mime-disrespect, because
the authoritative Content-Type is overridden by external reference.
The difference between client-side and server-side XSLT is the output
processor stage.  A server-side transformation is A + B = C, but on the
client the transformation is A' + B = A because output processors in
browsers manipulate the loaded DOM directly.

In browsers, the media type of the XSLT output is always the media type
of the document that calls the XSLT.  That authoritative metadata is
what sets the browsing context, before and after transformation.
Unless someone knows of a browser that supports <xsl:output/> ?  You
aren't loading a new browsing context, with its own URL and DOM, you're
merely altering the DOM the browsing context built when the URL was
dereferenced, before the XML PI was processed.

Using Opera with a clear cache, look at the NAG site and you'll see a
"flash of unstyled content" upon entry, because the browser renders the
source document as it's compiling the XSLT.  Following a link loads the
next page without the flash, now that the compiled XSLT is cached the
browser can stream the incoming XML document through it as soon as the
browser encounters the XSLT PI.  Following a link can change the
browsing context, an XSLT transformation can't -- you aren't creating an
ouput document, giving it an URL and redirecting there, even in a
virtual sense.

>
> The mime type of that document should reflect the document not the
> result of some referenced transformation. (It's currently served as
> text/xml, probably now application/xml would be recommended but it's a
> very old document)
> 

The media type is set by the Content-Type header of the document
calling the transformation.  GRDDL links to an XSLT transformation, but
not for in-browser processing.  The GRDDL transformation occurs out-of-
browser, because it requires support for <xsl:output/> to properly
set the RDF media type.

>
> But with XSLT the source DOM is never rendered,
> XSLT never edits in place; it generates a completely new document and
> it is this new (x)html document that is rendered by the browser.
> 

The source-document DOM is always there.  You only think you're
creating a new document when you match='/' and overwrite the source
document entirely.  The true behavior of browser-resident XSLT is the
manipulation of the DOM the browser built from the source document.  If
the browser were creating a new DOM then the back button would take you
back to the source document, and return you to the output document
after re-running the transformation.

-Eric

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.