Re: Managing semi-trivial sets of stylesheets.

> > 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
> http://www.pault.com/servlet/GetStylesheetModule?name=a.xsl
> 
> 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
better...

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 
  java.io.IOException, 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 
place.

Rgds.Paul.

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



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list