Re: Simple and powerful [Re: Managing semi-trivial sets ofstylesheets.]

[Paul Tchistopolskii <paul at qub dot com>]

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