You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Norman Walsh <nd...@nwalsh.com> on 2000/07/30 16:52:24 UTC

Re: Using a custom org.xml.sax.EntityResolver with Xalan

Unfortunately, Xalan does not pass the xsl:include, xsl:import, or
document() URIs through the entityResolver.

Digging about, it was fairly easy to coerce Xalan to use the
entityResolver in the actual parsing. In XSLTEngineImpl, instead
of

  XSLTInputSource inputSource = new XSLTInputSource(url.toString());
  m_parserLiaison.parse(inputSource);

simply pass the systemId to the parse method:

  m_parserLiaison.parse(url.toString());

and in XMLParserLiaisonDefault, instead of

    InputSource source = new InputSource(systemId);

actually use the resolver if it's available

    InputSource source = null;
    if (null != m_entityResolver) {
	source = m_entityResolver.resolveEntity(null, systemId);
    }
    if (null == source) {
	source = new InputSource(systemId);
    }

Unfortunately, this effort is for naught because Xalan assumes that
it can calculate the absolute URI much earlier, for example in
StylesheetHandler

  URL hrefUrl
      = m_processor.getURLFromString(href, 
                                     ((URL)m_stylesheet.m_includeStack.peek()).toString());

and it subsequently uses that URL (squirreled away on the includeStack)
to calculate absolute URIs.

All of which means that the following doesn't work:

1. I have a stylesheet that includes a base stylesheet:

   <xsl:include href="http://nwalsh.com/xsl/docbook/html/docbook.xsl"/>

2. I have an entity resolver that knows that I have a local copy of
   that stylesheet, so it opens file:///share/xsl/docbook/html/docbook.xsl
   instead.

3. That stylesheet contains a relative URI in an xsl:include of its own:

   <xsl:include href="../VERSION">

4. The StylesheetHandler calculates the absolute uri of VERSION as

      http://nwalsh.com/xsl/docbook/VERSION

   which largely defeats the purpose.

My first attempt at passing information about the modified systemId
back up stream was to get the document back from the parse:

   Document doc = m_processor.parseXML(hrefUrl,
				 this, m_stylesheet);

and examine the systemId of the DocumentType on that document, but
those functions aren't supported in Xalan.

This leads me to a few questions.

Q: Is the functionality I want controversial? Does anyone believe that
these URIs should not be passed through the entityResolver?

Q: Am I the only one who cares :-)

Q: Assuming the answers are no, and no, respectively, can someone more
familiar with the overall Xalan architecture see an elegant solution
to the problem?

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM | Simplicity is always a virtue.--Edward Abbey
XML Technology Center     | 
Sun Microsystems, Inc.    |