[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
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|