Project

Profile

Help

Forums » Help »

custom XmlResolver gets discarded ...

Added by Anonymous over 16 years ago

Legacy ID: #4738751 Legacy Poster: Peter Mei (pmei)

A custom System.Xml.XmlResolver registered with the Saxon processor appears to be discarded when constructing a new DotNetPullProvider in net.sf.saxon.dotnet.DotNetPlatform.getParserSource(...). Here is my scenario. I have a collection of stylesheets, schemata and a few parsed entities which are used by an application, and which -- while describing namespaces whose URIs are valid and accessible when online -- need to be packaged into the application as embedded resource streams. I've implemented an XmlResolver which intercepts the appropriate URIs and supplies entity content from the appropriate resources. However, only the primary stylesheet is utilizing the custom resolver. All URI and entity resolution in imported documents is being performed by an instance of the default resolver (System.Xml.XmlUrlResolver) which attempts to load the resources by dereferencing their URIs which is not the desired behavior. I have assigned my custom resolver to the exposed XmlResolver property at all opportunities: Saxon.Api.Processor.XmlResolver Saxon.Api.XsltTransformer.InputXmlResolver Saxon.Api.XsltCompiler.XmlResolver System.Xml.XmlReaderSettings.XmlResolver I've examined the Saxon source and it would seem that the relevant call is atop the following stack trace ... -----snip----- at net.sf.saxon.dotnet.DotNetPlatform.getParserSource(Configuration, StreamSource, Int32, Boolean, Int32) at net.sf.saxon.event.Sender.send(Source, Receiver, Boolean) (~Sender.java:170) at net.sf.saxon.event.Sender.send(Source, Receiver) at net.sf.saxon.PreparedStylesheet.loadStylesheetModule(Source, Configuration, NamePool, StyleNodeFactory) at net.sf.saxon.style.XSLGeneralIncorporate.getIncludedStylesheet(XSLStylesheet, Int32) at net.sf.saxon.style.XSLStylesheet.spliceIncludes() at net.sf.saxon.style.XSLStylesheet.preprocess() at net.sf.saxon.PreparedStylesheet.setStylesheetDocument(DocumentImpl, StyleNodeFactory) at net.sf.saxon.PreparedStylesheet.prepare(Source) at net.sf.saxon.TransformerFactoryImpl.newTemplates(Source, CompilerInfo) at Saxon.Api.XsltCompiler.Compile(XmlReader) -----snip----- While I am less facile with the javax.xml.transform.sax.*-based branch that the Java platform would follow in (Sender.java:172-187), it does appear to me that there the original XMLReader (as 'parser') is preserved, along with any customized EntityResolver registered thereupon. In the .NET platform's branch, the only data retained from the API client's context are the system ID, the underlying byte or character stream, the numeric schema validation mode, and the boolean DTD-validation flag. Am I completely down the wrong track, or is this a platform-specific bug?


Replies (4)

Please register to reply

RE: custom XmlResolver gets discarded ... - Added by Anonymous over 16 years ago

Legacy ID: #4738778 Legacy Poster: Peter Mei (pmei)

Here is a reduction of the relevant files, for clarity. the primary stylesheet: -----snip----- <!DOCTYPE stylesheet [ <!ENTITY % SomeCommonEntities SYSTEM "http://do.not.actually.deref/1"> %SomeCommonEntities; ]> <xsl:stylesheet version="2.0" id="primary_stylesheet" ...> <xsl:import href="http://do.not.actually.deref/2&quot;/> </xsl:stylesheet> -----snip----- the imported stylesheet, identified by 'http://do.not.actually.deref/2' -----snip----- <!DOCTYPE stylesheet [ <!ENTITY % SomeCommonEntities SYSTEM "http://do.not.actually.deref/1"> %SomeCommonEntities; ]> <xsl:stylesheet version="2.0" id="imported_stylesheet" ...> </xsl:stylesheet> -----snip----- _ sequence of entity resolution, etc., according to logs and stack traces _ 1. "http://do.not.actually.deref/1" is resolved by the custom resolver (successfully) 2. content for same is retrieved by the custom resolver 3. "http://do.not.actually.deref/2" is resolved by the custom resolver (successfully) 4. content for same is retrieved by the custom resolver 5. "http://do.not.actually.deref/1" is resolved by the default resolver without having been delegated to by the custom resolver. I can also provide a variety of stack dumps, as needed.

RE: custom XmlResolver gets discarded ... - Added by Anonymous over 16 years ago

Legacy ID: #4740204 Legacy Poster: Michael Kay (mhkay)

Thanks for reporting it. It was the design intention that the supplied XmlResolver should be used for all URI dereferencing including dereferencing of external entity references by the XML parser assuming that the XML parser is created by Saxon (rather than being supplied by the user). However, because the Java JAXP approach uses two different classes - a URIResolver for the XSLT-level URIs and an EntityResolver for those at the XML level - this hasn't been carried through, and the XmlResolver is being used only for those URIs that Saxon itself dereferences. Also, I don't think the intent is clearly documented. I'll try to make it work (and document it) the way it was intended. Meanwhile, I think the workaround is to build all source documents yourself using the DocumentBuilder.Build(XmlReader) method. This allows you to configure the XmlReader yourself.

RE: custom XmlResolver gets discarded ... - Added by Anonymous over 16 years ago

Legacy ID: #4742117 Legacy Poster: Michael Kay (mhkay)

I have now made and tested the changes needed to ensure that the nominated XmlResolver gets used by the XML parser when resolving external entity references, as well as being used by Saxon itself. The changes are rather too extensive, I'm afraid, to issue as a patch, so they will have to wait until the next full release. Michael Kay

RE: custom XmlResolver gets discarded ... - Added by Anonymous over 16 years ago

Legacy ID: #4742211 Legacy Poster: Peter Mei (pmei)

That's fine. I'm not surprised that the changes were broad; it did look as if a fix might require some small procedural shift in the handling of Sources, rather than just adding a few instructions, which is why I wasn't terribly keen on using a locally customized build. Thank you very much for the swift response!

    (1-4/4)

    Please register to reply