Bug #1603
closedCannot load XML with same URI as the host page
100%
Description
Using script element to invoke Saxon-CE with SaxonceDebug and omitting the logLevel URI parameter gives this error message:
[14.08.2012 16:16:23] JavaScript - http://test.rudolphina.org/SaxonceDebug/8F77957029E1C121EE89B4E62B41B174.cache.html
console.error
SaxonCE.Xstl20Processor 16:16:23.370
SEVERE: Cannot load XML with same URI as the host page
Same on file:// protocol, seems not to depend on namespace. Works as expected with logLevel specified.
Files
Updated by Philip Fearon over 12 years ago
This restriction is by design - it was introduced in response to a reported bug that was caused by ambiguity on whether the context node for an xsl:result-document instruction was associated with the XML source or the host HTML page. Omitting the logLevel URI parameter should not affect this behaviour - so this inconsistent behaviour would be a bug. I will check back through the issues log to identify the original issue that led to this restriction being introduced.
Updated by Manfred Staudinger about 12 years ago
I would like some advice for debugging further. Just to recap:
-
I'm fine with this restriction, but my program does no such load, it's done by SaxonceDebug.
-
To avoid this error it is sufficient to add a "?" in the browsers address bar. This most probably means Saxon-CE takes the full URI for comparison but should take the URL part only.
-
The very same program executed with Saconce succeeds without error (a bit disturbing).
Updated by Philip Fearon about 12 years ago
The restriction means that the following line within test.html
fails:
<script type="application/xslt+xml" language="xslt2.0" src="Ind_Pers_de.xsl" data-source="test.html"></script>
The data-source attribute, test.html
is the same URL as the page containing this script
element. Because the ixsl:page()
function is used to access the host page DOM, you don't need to set test.html
as the data-source also - and there's the potential for confusion/ambiguity if you do - hence the restriction.
When you're not interested in another XML data-source you still need an 'entry-point' for the XSLT processor, the approach here would normally be to set the initial template name instead, like 'main' as shown in the example below:
<script type="application/xslt+xml" language="xslt2.0" src="Ind_Pers_de.xsl" data-initial-template="main"></script>
With this set, all that remains is to change the entry-point template to be named 'main', instead of having a match="/"
attribute - as follows:
<xsl:template name="main">
<xsl:result-document href="#htmlbody" method="ixsl:replace-content">
<xsl:apply-templates select="ixsl:page()/*/*/*[@id='htmlbody']/*" mode="init"/>
</xsl:result-document>
</xsl:template>
Fortunately, your code was already using ixsl:page()
(instead of the context node) to access the document node - so the unaltered select
attribute value in the apply-templates
instruction in your code should have the desired effect.
The bug that causes different behaviours depending on URLs and Saxon/SaxonDebug versions will be fixed for the next maintenance release. I should also mention that if you need to set the Saxon logLevel without using a URL parameter (like this case when the URL affects behaviour) you could use the alternative JavaScript API instead of the xslt2.0 script
element as follows:
<script type="text/javascript" language="javascript">
onSaxonLoad = function() {
proc = Saxon.run( {
stylesheet: 'Ind_Pers_de.xsl',
initialTemplate: 'main',
logLevel: 'FINEST'
} );
}
</script>
Updated by O'Neil Delpratt over 11 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
- Found in version set to 1.0
- Fixed in version set to 1.1
Fixed in Saxon-CE 1.1 release
Updated by O'Neil Delpratt over 11 years ago
- Status changed from Resolved to Closed
- Sprint/Milestone set to Release 1.1
Bug fixed for Saxon-CE version 1.1 release
Please register to edit this issue