Re: Managing semi-trivial sets of stylesheets.

Subject: Re: Managing semi-trivial sets of stylesheets.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Wed, 07 Jun 2000 03:47:27 -0700
> > 1. I don't like the absolute path because:..
> > 2. I don't like the relative path because:..
> > Is there some  'XML mainstream' solution to this small problem? 
> If you really feel strongly about it 

Unfortunately yes ...  I am building the framework which is based 
on the idea that there are many small  stylesheets ... combined in 
some ways...

> you could use a URL such as
> and write the relevant servlet.

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

import org.xml.sax.*;
import com.pault.ux.FS;

 * Creation date: (6/1/00 1:53:41 PM)
 * @author: Paul Tchistopolskii

public class UxSpecialXMLParser extends com.jclark.xml.sax.CommentDriver {

 public void parse(org.xml.sax.InputSource in) throws, org.xml.sax.SAXException {

   String sysid =  in.getSystemId();
   if ( sysid.startsWith("file:") && !sysid.startsWith("file:" + FS.m_Root ) ) {
     in.setSystemId( "file:" + FS.m_Root + sysid.substring(5) );
   super.parse( in );


Setting this 'parser'  for  XT allows me to write 
<xsl:include = "/stdio/common.xsl"/> and then don't care about the 
prefix directory.

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 


PS. Eric suggested entities to do the same, but I'm almost afraid of 

 XSL-List info and archive:

Current Thread