Project

Profile

Help

Actions
Send by e-mail Copy link

Bug #4993

closed

java.lang.IllegalStateException: Prefix is bound to the wrong namespace {http://www.deltaxml.com/ns/mini-xhtml}

Added by Philip Fearon over 3 years ago. Updated over 3 years ago.

Status:
Duplicate
Priority:
Low
Assignee:
Michael Kay
Category:
-
Sprint/Milestone:
-
Start date:
2021-05-18
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
10
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

This exception is thrown in Saxon 10.5 by an XSLT transform deep within our product's Java filter-chain class. The XML source file ([00-2]-dxml-whitespaceDetection.xml) for the transform (attached) has a root element in the default namespace (i.e. with no prefix).

I'm afraid I can't reproduce this exception yet in a simple test case outside our own products XSLT pipeline infrastructure.

Running the same transform from the command-line or a simplified Java Saxon API test does not reproduce the issue.

The full stack trace (when running testng) is shown at the end. The input file to the transform is attached.

A simplified version of the stylesheet that still throws the exception is shown below. Note that replacing the xsl:copy-of instruction and uncommenting the xsl:apply-templates instruction that is on the following line seems to be a viable workaround.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                exclude-result-prefixes="#all"
                version="3.0">
  
  <xsl:mode on-no-match="shallow-copy"/>
  
  <xsl:template match="/*">
    <xsl:copy>
      <xsl:copy-of select="node()"/>
      <!-- <xsl:apply-templates select="node()"/> -->
    </xsl:copy>
  </xsl:template>
  
</xsl:stylesheet>

Some additional context: We're in the process of adding Saxon 10.n compatibility to our Java project that currently supports Saxon 9.8 and 9.9. This problem appears in a number of our regression tests when run with Saxon 10.5, the same exception is not thrown with Saxon 9.8 or Saxon 9.9 versions. Here's the stack trace:

java.lang.RuntimeException: Internal error evaluating template rule  at line 8 in module file:/Users/philipf/dev/core/test/resources/xsl/formatting/rename-formatting.xsl
 at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:403)
 at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:568)
 at net.sf.saxon.trans.rules.ShallowCopyRuleSet.process(ShallowCopyRuleSet.java:73)
 at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:530)
 at net.sf.saxon.trans.XsltController.applyTemplates(XsltController.java:661)
 at net.sf.saxon.s9api.AbstractXsltTransformer.applyTemplatesToSource(AbstractXsltTransformer.java:360)
 at net.sf.saxon.s9api.XsltTransformer.transform(XsltTransformer.java:349)
	at com.deltaxml.cores9api.XsltStep.internalRunStep(XsltStep.java:173)
	at com.deltaxml.cores9api.RunnableFilterChain.runFilterChain(RunnableFilterChain.java:171)
	at com.deltaxml.cores9api.RunnableFilterChain.runFilterChain(RunnableFilterChain.java:353)
	at com.deltaxml.cores9api.PipelinedComparatorS9$Input1Runner.run(PipelinedComparatorS9.java:2383)
	at com.deltaxml.cores9api.PipelinedComparatorS9.compareXdmNode(PipelinedComparatorS9.java:1401)
	at com.deltaxml.cores9api.PipelinedComparatorS9.compare(PipelinedComparatorS9.java:1282)
	at com.deltaxml.cores9api.DocumentComparator.compare(DocumentComparator.java:1939)
	at com.deltaxml.cores9api.AbstractComparator.compare(AbstractComparator.java:387)
	at com.deltaxml.cores9api.DocumentComparator.compare(DocumentComparator.java:127)
	at com.deltaxml.cores9api.IgnorableWsPreservationTest.runSelectiveTestComparison(IgnorableWsPreservationTest.java:163)
	at com.deltaxml.cores9api.IgnorableWsPreservationTest.testIgnorableWsContent(IgnorableWsPreservationTest.java:85)
 at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
 at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
 at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719)
 at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989)
 at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
 at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
 at org.testng.TestRunner.privateRun(TestRunner.java:648)
 at org.testng.TestRunner.run(TestRunner.java:505)
 at org.testng.SuiteRunner.runTest(SuiteRunner.java:455)
 at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:450)
 at org.testng.SuiteRunner.privateRun(SuiteRunner.java:415)
 at org.testng.SuiteRunner.run(SuiteRunner.java:364)
 at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
 at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:84)
 at org.testng.TestNG.runSuitesSequentially(TestNG.java:1208)
 at org.testng.TestNG.runSuitesLocally(TestNG.java:1137)
 at org.testng.TestNG.runSuites(TestNG.java:1049)
 at org.testng.TestNG.run(TestNG.java:1017)
 at org.testng.TestNG.privateMain(TestNG.java:1354)
 at org.testng.TestNG.main(TestNG.java:1323)
Caused by: java.lang.IllegalStateException: Prefix  is bound to the wrong namespace {http://www.deltaxml.com/ns/mini-xhtml}
 at net.sf.saxon.event.RegularSequenceChecker.startElement(RegularSequenceChecker.java:368)
 at net.sf.saxon.event.ComplexContentOutputter.startElement(ComplexContentOutputter.java:530)
 at net.sf.saxon.tree.tiny.TinyElementImpl.copy(TinyElementImpl.java:388)
 at net.sf.saxon.expr.instruct.CopyOf.copyOneNode(CopyOf.java:629)
 at net.sf.saxon.expr.instruct.CopyOf.lambda$processLeavingTail$1(CopyOf.java:561)
 at net.sf.saxon.om.SequenceIterator.forEachOrFail(SequenceIterator.java:136)
 at net.sf.saxon.expr.instruct.CopyOf.processLeavingTail(CopyOf.java:559)
 at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:142)
 at net.sf.saxon.expr.instruct.ElementCreator.processLeavingTail(ElementCreator.java:352)
 at net.sf.saxon.expr.instruct.Copy.processLeavingTail(Copy.java:429)
 at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(TemplateRule.java:384)
 ... 42 more

Files

Download all files
[00-2]-dxml-whitespaceDetection.xml (1.08 KB) [00-2]-dxml-whitespaceDetection.xml Philip Fearon, 2021-05-18 13:12
rename-formatting.xsl (417 Bytes) rename-formatting.xsl Philip Fearon, 2021-05-18 13:12
Actions
Copy link
 #1

Updated by Michael Kay over 3 years ago

Thanks for reporting.

The error is detected in the RegularSequenceChecker which sits between the XSLT engine and its output pipeline (usually a serializer) and checks that the sequence of events passed down the pipeline is consistent. The intent is that the RegularSequenceChecker is present in the pipeline only when Java assertions are enabled, so you may be able to bypass the checks by removing the -ea switch.

The particular message indicates a startElement event with an element name having no prefix, when the NamespaceMap on the same event indicates that the empty prefix is bound to a different namespace. This certainly is something that shouldn't happen, though it's entirely likely that if we didn't check for it (which in earlier releases we didn't), no one would ever notice a problem.

The TinyElement.copy() code that generated this startElement() event mentions bug #2209.

Actions
Copy link
 #2

Updated by Philip Fearon over 3 years ago

OK thanks, with your comment on the -ea switch, I understand better now why I couldn't reproduce this error outside of our TestNG environment.

Our main objective is to ensure the tests pass with Saxon 10.n. I don't yet know quite how our preceding XSLT transform in the pipeline is managing to produce a startElement with no namespaceURI. I'm hoping we can find a workaround using xsl:apply-templates instead of xsl:copy-of

Actions
Copy link
 #3

Updated by Michael Kay over 3 years ago

I'm wondering if the inconsistency might already be present in the source document to the transform. How do you pass documents between stages of the pipeline (lexical XML, event sequence, or node tree)? If it's in the form of a TinyTree, then capturing the structure using TinyTree.diagnosticDump() might yield insights.

Actions
Copy link
 #4

Updated by Philip Fearon over 3 years ago

I'm checking for an inconsistency at the moment. For parsing the lexical XML, we extend org.xml.sax.helpers.XMLFilterImpl to gather lexical information that would otherwise be discarded by the parser. We are seeing another test failure (that passes with Saxon 9.8/9.9) that just might be related to this issue (and may prove easier to analyse).

In this other case, with Saxon 10.5 we're losing the namespace (the same as in this case http://www.deltaxml.com/ns/mini-xhtml) of an XML attribute - not present in the input XML but present solely because its defined in the XML Schema as a default attribute with a default value.

For info, the XML below is the Saxon 9.8 output from what I believe is our first XSLT filter following the parser:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" xmlns:preserve="http://www.deltaxml.com/ns/preserve" xmlns:er="http://www.deltaxml.com/ns/entity-references" xmlns:pi="http://www.deltaxml.com/ns/processing-instructions" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:_2="http://com.deltaxml.test/namespace" xsi:noNamespaceSchemaLocation="mini-xhtml-default-att.xsd" _2:test="yes" preserve:defaultAttributes="{http://com.deltaxml.test/namespace}test" preserve:grammar="schema">
  <preserve:xmldecl xml-version="1.0" encoding="UTF-8"/>
  <head>
    <title>hello world</title>
  </head>
</html>

The output from Saxon 10.5 is:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" xmlns:er="http://www.deltaxml.com/ns/entity-references" xmlns:pi="http://www.deltaxml.com/ns/processing-instructions" xmlns:preserve="http://www.deltaxml.com/ns/preserve" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="mini-xhtml-default-att.xsd" test="yes" preserve:defaultAttributes="{http://com.deltaxml.test/namespace}test" preserve:grammar="schema">
  <preserve:xmldecl xml-version="1.0" encoding="UTF-8"/>
  <head>
    <title>hello world</title>
  </head>
</html>

So, the significant difference is that Saxon 10.5 the attribute named test is in the null namespace rather than the http://com.deltaxml.test/namespace namespace in the 9.8 result that is bound to the _2 prefix.

I'll report back when I have looked at this in more details - the two cases may not be directly related.

Actions
Copy link
 #5

Updated by Michael Kay over 3 years ago

My guess is that this is the same problem as #4996, caused by Xerces failing to declare a namespace (or prefix) when it injects a default attribute whose name is namespaces, as a result of Xerces schema validation.

I've run the test case for bug #4996 on Saxon 9.8, and confirmed that it only works because of namespace fixup on the output pipeline; the inconsistent attribute (with a URI but no prefix) is accepted in the SAX input and stored "as is" in the TinyTree, where the consequences of the inconsistency are rather unpredictable.

I'd suggest that if we can't pin it down to a repro, we close this. Alternatively we could try building a version of 10.x with the patch in and trying that on your workload.

Actions
Copy link
 #6

Updated by Michael Kay over 3 years ago

  • Status changed from New to Duplicate
  • Assignee set to Michael Kay

I think the evidence suggests that this has the same root cause as bug #4996, and the patch for #4996 should fix it, even though the symptoms are different.

Please register to edit this issue

Actions
Send by e-mail Copy link

Also available in: Atom PDF