Re: how does it fit in with the web

   I am very new to XSL and XML and don't quite understand how it fits in with
   the web?
   Is it intended that 
   1. an XSL processor sits on the server end, and generates html files? Or
   2. the web browser has an XSL processor, and so it downloads the XML file
   and corresponding XSL style sheet and generates the html itself?


Either of those. 

Whether the transformation is better to happen on the server or the
client depends on what it is.  Doing client side transformations means
that the client has access to the original markup which might be useful
(so save-as, or view-source show the original document, not the form
transformed for presentation) but if the original document is 1000Gb of
database and the transformation is pulling out one page of HTML, it may
be better to do the transformation on the server and so just send one
page down the wire.

Of course currently the usual situation is the web browser isn't XSL
aware (or at least isn't aware of the current draft) so server side
transformation is currently more common.

In either case you don't _have_ to transform to html. If your browser
is css aware you can transform to any XML together with presentation
specified by css, and hopefully one day browsers will natively
understand the XML markup that describes `XSL formatting objects'
in which case you could transform to them.

   Does anyone know of any perl implementations of an XSL processor?

No (well someone might, but I don't).
Java seems to be the language of choice for XSL developers

   Sam

David



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list