Project

Profile

Help

Bug #2872

closed

XSLT generates output with undeclared namespace prefix

Added by Michael Kay over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XSLT conformance
Sprint/Milestone:
-
Start date:
2016-08-10
Due date:
% Done:

100%

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

Description

From the saxon-help mailing list (Jorge Williams)

Found a weird regression when moving from Saxon 9.4.0-9 to Saxon 9.7.0-7. We have XSLTs that process XML Schemas. After we moved to the latest version of Saxon we found that in some cases the processor would output a result document with an xs prefix that isn’t actually bound to the XMLSchema namespace.

Was able to reproduce with this simple XSLT:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:foo="http://rackspace.com/foo"
   exclude-result-prefixes="xsd foo"
   version="2.0">

   <xsl:variable name="elem" as="element()"><element xmlns="http://www.w3.org/2001/XMLSchema"/></xsl:variable>

   <xsl:template match="/">
       <xsl:result-document href="foo.xml" exclude-result-prefixes="xsd foo">
         <foo:foo xmlns:xsd="http://www.w3.org/201/XMLSchema">
             <xsl:apply-templates select="$elem" mode="foo"/>
         </foo:foo>
       </xsl:result-document>
   </xsl:template>

   <xsl:template match="node()" mode="foo">
       <xsl:copy/>
   </xsl:template>


</xsl:stylesheet>

The result foo.xml looks like this:

<?xml version="1.0" encoding="UTF-8"?><foo:foo xmlns:xsd="http://www.w3.org/201/XMLSchema" xmlns:foo="http://rackspace.com/foo"><xs:element xmlns="http://www.w3.org/2001/XMLSchema"/></foo:foo>

Notice that the xs prefix is added but not defined, this didn’t happen in older versions. I know the example above is contrived, but we actually hit those operations in a complex production XSL.

Actions #1

Updated by Michael Kay over 7 years ago

  • Description updated (diff)
Actions #2

Updated by Jorge Williams over 7 years ago

Found a work around. Remove xsd from the exclude-result-prefixes at the stylesheet level and things work.

Actions #3

Updated by Michael Kay over 7 years ago

  • Status changed from New to In Progress

The problem occurs during serialization, which uses NodeName.getDisplayName() to determine the lexical QName of an element being serialized. The method getDisplayName() is normally used for diagnostics, where use of a conventional prefix for standard namespaces is appropriate; but here it is not.

It seems to be a consequence of the rewriting of the NamePool implementation in Saxon 9.7 (which until now has been remarkably trouble-free for such a radical change). NamePool.getDisplayName() when given a namecode < 1024 (indicating a name known to the system) is allocating a conventional prefix to the name, rather than using an empty prefix.

Actions #4

Updated by Michael Kay over 7 years ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 9.7 added

Fixed on the 9.7 branch by having NamePool.unprefixedQName() call a new method StandardNames.getUnprefixedStructuredQName() which returns a QName containing no prefix, rather than the conventional prefix.

The problem does not occur on the 9.6 or 9.8 branches, so no fix needed.

Actions #5

Updated by Michael Kay over 7 years ago

For completeness and future reference, here is a more definitive description of the bug.

When a document being serialized includes an element whose namespace is one of the "standard" namespaces usually associated with the prefixes xs, xsi, xsl, or saxon, and the element's name has no prefix, then Saxon serializes the element with the conventional prefix for that namespace, without ensuring that the namespace prefix is declared in the result document.

Actions #6

Updated by O'Neil Delpratt over 7 years ago

  • % Done changed from 0 to 100

Bug fix applied in the Saxon 9.7.0.8 maintenance release.

Actions #7

Updated by O'Neil Delpratt over 7 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.7.0.8 added

Please register to edit this issue

Also available in: Atom PDF