This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Cascading. ( Re: Recursive Template Application )
- To: xsl-list at mulberrytech dot com
- Subject: Re: Cascading. ( Re: Recursive Template Application )
- From: Matt Sergeant <matt at sergeant dot org>
- Date: Tue, 20 Jun 2000 23:18:22 +0100 (BST)
- Reply-To: xsl-list at mulberrytech dot com
On Tue, 20 Jun 2000, Paul Tchistopolskii wrote:
>
> From: Matt Sergeant
>
> > What I was saying was that you shouldn't have to specify the
> > stylesheets on any command line or in the querystring.
>
> Why?
Same reason you should use DOM and not some other invented API. Note the
english in use here: "shouldn't have to". Not at the exclusion of other
options.
> I think this is for sure easier to understand than 'alternate', 'persistant'
> e t.c. cascading stylesheets. When something is easeir to understand -
> I think that 'something' works 'better'.
Sure. Absolutely. You're free to do that. But you're missing the reason
I'm doing server side XSLT: eventually I want to deliver direct to the
browser. To do that you have to follow the spec.
> > AxKit does exactly
> > what a browser is meant to do: picks up the transformations from the
> > originating document via the <?xml-stylesheet?> processing
> > instructions. I'm sorry if I confused things by using your
> > "cat" command. I should have said its more like:
> >
> > "process some.xml"
> >
> > Where the process command picks out the stylesheets to use.
> >
> > (Note that for anyone interested in AxKit put off by this because it
> > doesn't scale well to 1000's of XML files, its all overrideable in various
> > different ways that do scale better)
>
> What do you mean?
I mean it doesn't have to work this way. People with experience in
building large scale systems based on Cocoon 1 will be the first to tell
you that adding <?xml-stylesheet?> PI's to every document is a pain in the
ass. So AxKit allows you to work however you want to work. It just happens
to default to the <?xml-stylesheet?> way of working.
> > In AxKit XSLT transformations don't have access to the querystring
> > parameters... yet. Its probably a bug. However you can use XSP or
> > XPathScript in places where you need access to the querystring.
>
> In AxKIt XSLT transformations don't have access to parameters ?????
They didn't until tonight. Just added that code. Remember that XSLT on
perl is very young, and AxKit is younger still.
> XSLT has some flaws, but I have to say that if I understand right that
> AxKit XSLT stylesheets have no <xsl:param top-level elements - AxKit
> point of view on XSLT stylesheet is very, very, very limiting to XLST
> developer.
Please limit your flames. You're using very derogator terms there. I just
said I added that facility. I said above it didn't do it "yet". It does
now. Happy?
I'm snipping the continued silliness about how <?xml-stylesheet?> is
broken. If you don't want to use that, then don't. I suggest not trying to
invent a new syntax though - write a NOTE for the W3C - we as developers
need standards, not thousands of different techniques for applying XSLT
styles to XML files. Its getting stupid now with all the different methods
available.
> Sounds interesting. But if Salbotron is not SAXParser you may
> find that chaining is not as flexible as you would like, ( for
> example, there could be no way to do:
>
> document("axkit:perl-bean1 | transformation.xsl")
So make your call to document() a http: request, and have it processed
directly with AxKit. Problem solved. Again - lets not invent a new
syntax. Lets hear it for standards.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list