[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
----- 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|