Re: Cascading. ( Re: Recursive Template Application )

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?

I think it is better to see what realy happens, what stylesheets
are applied e t.c.  BTW, in UX, because there are aliases similiar
to UNIX, the command :

cat some.xml |  aggregate.xsl mode="terse" | expand_widgets.xsl  |  render2html.xsl
font="big"

could be described in /etc/aliases.xml

<alias
 name="do_it"
 cmd="cat $1 |  aggregate.xsl mode='terse' | expand_widgets.xsl  |  render2html.xsl
font='big'"
/>

And will be invoked accessing url  /ux/Uxs?cmd='do_it%20some.xml'

So even the processing is complex - the 'things' are easy to maintain,
I think.

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'.

I like simplicity of UNIX and I don't like complexity of SGML.

> 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?

> 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 ?????
I don't understand how are you using XSLT then. In Ux,  XSLT stylesheets
not only have access to external parameters, but  are storing / reading
data in presistant HTTP sessions, cookies and do a lot  of other stuff.
( In fact my original  idea is to do almost everything in XSLT and I like
how it works ).

I found  XSLT to be good programming language ( even verbosity
is annoying and there are 2 other things waiting to be fixed - but let's
go step by step ;-).

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.

> > > Right. I'm not trying to flog AxKit to everyone here - most people will
> > > prefer a Java solution anyway (poor lost souls ;-)), just trying to point
> > > out that there is a standard for cascading that applies to XSLT.
> >
> > I don't think it makes too much sense with XSLT.
>
> Can you explain why? Obviously the W3C disagrees with you. We've discussed
> before how it doesn't exactly scale well to edit <?xml-stylesheet?>
> processing instructions into 100's or 1000's of XML files (but AxKit can
> cope with that too), but is there any other reason you think it doesn't
> make sense?

Because XSLT is not 'a bit better CSS' but it if full-blown
( and darn nice ) programming language for  XML processing
( not the end of the story, but ;-)

W3C is just inheriting their practices from one domain to another.
>From SGML to XML, from CSS to XSL. To me it is not too much
sense.

I agree that it may work for cases when XML + XSL
combination is used for producing one and only one
HTML file ( ever ).

( But when I have such a situation, I'l better to write only
one file ( XSL in HTML-ish template form ) - ( still no need
in hardcoded bindings ) )

OK, OK - people need this  way of binding for client-side ( I mean
they think they will need it for XSL because they need if for
CSS ), but because I not expect reliable client-side implementations
of XSLT  to appear in the near future, I'm discussing real
world. In the real world I *never* got the situation which forced me
to insert <LINK into XML file, binding it to some XSL stylesheet.

> > BTW - is Salbotron SAXParser?  Is it providing parse() and
> > setDocumentHandler() to  the perl code? If yes - you can
> > have the same document( "/! perl-bean1 | perl-bean2" )
> > in perl. Ux pattern is universal and should be easy to
> > re-implement in any language, because it is plain SAX
> > and nothing more.
>
> Sablotron allows you to provide scheme handlers, so I could add a scheme
> handler for "axkit:" and so support document("axkit:perl-bean1 |
> perl-bean2") or something like that. This isn't in the XML::Sablot
> interface yet, but its in the Sablotron interface, and I'm discussing
> adding it to the Perl interface for the next release so that AxKit can
> handle EPE's and document() better with Sablotron.

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")

( Supported by UX, because when everything is SAX - that rulezz ;-)

Rgds.Paul.



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