Re: Cascading. ( Re: Recursive Template Application )

Subject: Re: Cascading. ( Re: Recursive Template Application )
From: Matt Sergeant <matt@xxxxxxxxxxxx>
Date: Tue, 20 Jun 2000 13:46:55 +0100 (BST)
On Tue, 20 Jun 2000, Paul Tchistopolskii wrote:

> > Sure:
> >
> > "cat some.xml"
> >
> > The "cat" here picks up the stylesheets that are to be used from the
> > <?xml-stylesheet?> processing instructions, as per the w3c spec.
> Hmm... In my example, 'cat'  is:
> cat.xsl
>   <xsl:stylesheet version="1.0" xmlns:xsl="";>
>   <xsl:param name="ux-argv1" />
>   <xsl:template match="/">
>   <xsl:copy-of select="document( $ux-argv1 )" />
>   </xsl:template>
>   </xsl:stylesheet>

Yep, that's just a copy of Unix cat, only with an XML parser in
front. What I was saying was that you shouldn't have to specify the
stylesheets on any command line or in the querystring. 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)

> I wish you also have another 'standard'  answer regarding:
> cat some.xml |  aggregate.xsl mode="terse" | expand_widgets.xsl  |  render2html.xsl
> font="big"
> ( I think that tuning transformations with some parameters is unavoidable
> thing in the real life. Can you imagine scripts without parameters?  Scripts are
> transformations ).

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.

> > > I'm sorry if it was  not appropriate to place this view on chaining
> > > in reply to your letter ( because I now realize that your leter was
> > > actualy talking about the standards which are good for us, right ? )
> >
> > 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?

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


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability. | AxKit:

 XSL-List info and archive:

Current Thread