On Mar 2, 2004, at 7:02 PM, Scott Shipley wrote:[xslt]Basically it matches patterns with templates. I've only ever used it for source code documentation, to transform Docbook XML into XHTML + css.
Here's some more detailed info on how it might relate to a browser:
http://devedge.netscape.com/library/manuals/2001/xslt/1.0/
The attractiveness of XSLT for me is the continued separation of web page data from formatting and layout information, something which, to my mind, is only partially addressed by the (X)HTML+CSS paradigm. Basically, I like the idea of being able to serve the essential information from my site in XML -- this being pure data, devoid of all extraneous layout/formatting control -- and tailor this single datastream (supplied by a single, constant code-layer on my server) to different user applications AT THE CLIENT end, through the delivery of appropriate XSLT stylesheets to control the final rendering.
[For those who don't know, the process goes something like this:
- browser requests the page;
- server returns page data as XML, together with location of XSLT transformation template (misnamed a 'stylesheet' from now on!);
- browser requests the specified stylesheet;
- server returns the stylesheet;
- browser applies the stylesheet to the xml, transforming it into something the browser can render (usually html);
- the transformation may include css styling instructions, which may be referenced in additional CSS stylesheets; if so:
- browser requests the css stylesheets;
- server returns the stylesheets;
- browser applies the stylesheets;
- (finally!) browser renders the transformed and formatted page.
]
At first sight, the increased complexity of the delivery and rendering process may look to offer nobody any great advantage, but this is far from the truth. This model shifts a lot of the decision-making within the delivery of dynamic page content from the server end to the client. Which means the user gets the data faster. It also clearly separates the development of content delivery (done within the XML) from development of presentation (done with the xslt) thus allowing large enterprises to deploy separate teams to work on each aspect, with greater chance of the combined efforts being fruitful!
All of which makes complex, dynamic web-sites easier to develop. (And no, I can see no advantage of XSLT on static sites, whatsoever.)
The advantages go beyond simply making my life as a site developer easier, though. End users should benefit from improved download times, as well as potentially getting improved flexibility in the way they view what comes back from a site. Take, for instance, the viewing of on-line catalog information. If a site offers different ways of ordering such information, say, by price, or by manufacturer, ascending or descending, when a user flips between the different modes of browsing, the underlying data doesn't need to re-selected, grouped and sorted by the server. The same data as before is applicable, only a different stylesheet needs to be sent, and the browser told how to reorder and rearrange the display locally.
Or, should a user be browsing through lots of entries in a database, where the layout and "window dressing" (such things as captions to the data and so on) does not vary, again all the browser needs to renew on each new page access is the underlying data, not the XSLT or CSS stylesheets, which will remain cached and available for use immediately.
All of this is more than theory, or tempting technology over the horizon. Other Mozilla browsers have supported XSLT transformation since I can't remember when (certainly my old Mozilla 1.0.2 on MacOS 9 does it, albeit rather clunkily) and Win IE has supported it since IE5.5 (though with the usual Microsoft departures from standards, needless to say!)
[If you want to see a real page, point any Mozilla browser other than Camino at http://www.stonegnome.info/music/xml/displayx.php?dthome. And then at http://www.stonegnome.info/music/xml/displayx.php?fd. You should find the second page comes down much faster than the first, even though it looks longer. Now view the source: notice how there is absolutely no formatting info there. Additionally, see how information that appears in multiple places in the rendered page (each CD appears in the rendered document at least twice, for instance, first in a sort of menu form, and secondly in detail form, but the source only has the information once.) Now see why I'm evangelising? :) (These pages are not at production level yet, btw: they are not publically linked and are experimental and development, so don't expect any links on them to necessarily work! They're there to demonstrate the feasibility of the technology!) ]
Moreover, the Amazon Developers' Program offers free access to the Amazon on-line catalog for Amazon Associate sites (of which there are now many thousands around the world). Data retrieved from search calls into the catalog comes, surprise, surprise, in the form of XML and includes everything that Amazon know about the product, including current price and availability information from Amazon in the US, UK, Germany and Japan! As part of the (free!) service, Amazon allow the uri of an XSLT stylesheet to be included in the call to their servers: this will be loaded and applied by the server before your data is returned, so that you can prune the data to your precise requirements, (or format it prettily, ready to pass on). Now, there are a good many evils associated with server-side XSLT, which needn't concern us here (interested parties can read http://people.opera.com/howcome/1999/foch.html) but what is important here, I think, is to note that Amazon are currently breeding a culture of routine XML/XSLT use which can only expand as people grasp its power. Already, Amazon are having to impose restrictions on its use on their servers: they limit the size of the XSLT stylesheets that they accept, as well as the frequency of your calls. In just six months, they have relaxed the rule that prevented associate sites from caching Amazon catalog data (fearing that it would then be allowed to age) to a new rule that says data can be cached for up to 24 hours, provided the associate site carries a warning that the information may be out of date.
Having acquired a taste of the power that XSLT provides, it is only a matter of time (and for some of us, that time is at hand!) before associate sites realise just how much more power they would have by delivering in that form themselves. Rather than waste processing power on their own (or Amazon's) servers, data can be passed on in a raw form to whoever requests it, merely with a pointer to added (formatting) instructions, should it be a rendering agent that made the request.
This is the way the web (or at least, the commercial web) is moving. <rant>Camino needs to move with it.</rant> :)
-Steve
_______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
