[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Simple and powerful [Re: Managing semi-trivial sets ofst

Subject: Re: Simple and powerful [Re: Managing semi-trivial sets ofstylesheets.]
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Fri, 09 Jun 2000 19:54:29 -0700
ofst
----- 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.