This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Simple and powerful [Re: Managing semi-trivial sets ofstylesheets.]
----- Original Message -----
From: Eric van der Vlist
> > > Or you could stick a SAX filter between the stylesheet parser and the XSLT
> > > processor.
> >
> > That's what I did - I was wondering maybe there is something
> > better...
> >
> > <nice code snipped/>
> >
> > The side-effect with XT ( and I guess with any other XSLT implementation )
> > is that this affects document() as well, because document() invokes the
> > same parser ;-) But this is OK with me - makes life even easier, because
> > moving the entire project to any directory requires changing only one
> > place.
> >
>
> This SAX filter can easily be extended to do any mapping using the
> "file:" URI scheme, making it quite easy for content management systems.
>
> It has the benefit to set up an artificial root restricting the access
> to the file system which can be useful for security reasons on multi
> hosted web systems.
>
> I wonder how easy it would be to define other pseudo schemes...
>
> A "java:" pseudo scheme calling a class and considering its output as a
> XML document would make the link with some of your previous posts
> (http://www.mulberrytech.com/xsl/xsl-list/archive/msg10225.html).
Not sure about 'java:' ( why should we introduce yet another
binding mechanism instead of current ( even vendor-spefic )
namespace-based binding ) ?
> Even with the limitation that acting as it is a filter you are not aware
> of the XSLT context, it could be worth trying...
I'm using the following tricks in my framework
( no changes to XT code, UxSpecialXMLParser does everything ) :
<xsl:variable name="filelist" select="document('/! ls /usr/lib')" />
Much faster than 'mainstream' way with HTTP + XML parsing
e t.c. And it is also extremely scalable. ( 'ls' is a 'ux-bean' . To write
your own ux-bean you need to implement only one straighforward
function and then drop the .class file into particular directory ).
By the way:
<xsl:variable name="filelist"
select="document('/! ls mode=verbose /usr/lib | sort.xsl type=bytype ')" />
also works. There are many nice tricks one can do with plain SAX and XT.
I think I'l publish this Ux-thing next 30 days. The sad story is that I can not
spend a week porting the entire thing to SAXON or Xalan, because
SAXON and Xalan have a bit different design than XT.
Rgds.Paul.
PS. Frankly, even the SAXParser-based hack works, I'm not very happy with
the way I did it, because I think better way was to have URIResolver in
SAX ( like there is EntityResolver ). Some job is needed to wrap a
reasonable common extension/binding API for XSLT processors and
then adjust all the existing processors to that API.
I can not belive this will gonna happen soon, because XSLT-related
functionality should be 'syncronized' with XML-related functionality
( SAX and DOM), but I think when it comes to such syncronizations
W3C usualy spends years on even simple things. Of course, when something
is driven by only one group ( or only one person ) - W3C works 10-20 times
as fast, but something tells me that we have another situation with XSLT
extensions / binding.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list