Re: Cascading. ( Re: Recursive Template Application )

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