Project

Profile

Help

Bug #1603

closed

Cannot load XML with same URI as the host page

Added by Manfred Staudinger over 11 years ago. Updated about 11 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Sprint/Milestone:
Start date:
2012-08-14
Due date:
% Done:

100%

Estimated time:
Platforms:

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

test.html (1.12 KB) test.html Manfred Staudinger, 2012-08-14 14:32
Ind_Pers_de.xsl (2.83 KB) Ind_Pers_de.xsl Manfred Staudinger, 2012-08-14 14:32
Actions #1

Updated by Philip Fearon over 11 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.

Actions #2

Updated by Manfred Staudinger over 11 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).

Actions #3

Updated by Philip Fearon over 11 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>
Actions #4

Updated by O'Neil Delpratt about 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

Actions #5

Updated by O'Neil Delpratt about 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

Also available in: Atom PDF