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: Paul Tchistopolskii <paul at qub dot com>
- Date: Tue, 20 Jun 2000 11:22:24 -0700
- Organization: The Qub Group
- References: <Pine.LNX.4.21.0006201306580.18513-100000@ted.sergeant.org>
- Reply-To: xsl-list at mulberrytech dot com
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