Project

Profile

Help

Support #6315

closed

<xsl:copy-of copy-namespaces="no" select="./*"/> is not working

Added by Lahiru Madushanka 11 months ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2024-01-11
Due date:
% Done:

0%

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

Description

We have been utilizing Saxon-HE jars in our product for XSLT use cases.

Recently, we upgraded the Saxon version used in our products from 9.5.1-8 to 10.8. Following this upgrade, one of our customers encountered an issue, which is documented in [1]. Despite the issue description indicating that it was resolved in maintenance versions 9.9.1.8 and 10.3, we are still observing the issue in version 12.4.

I am providing a sample java project to reproduce the issue. If we change the dependency to 9.5.1-8 dependency, we get the correct output without namespaces. else we get the output with namespaces.

[1] https://saxonica.plan.io/issues/4793


Files

testProject.zip (11.6 KB) testProject.zip Sample Java client Lahiru Madushanka, 2024-01-11 11:14
Screenshot 2024-01-11 at 15.55.24.png (73.8 KB) Screenshot 2024-01-11 at 15.55.24.png version 12.4 output Lahiru Madushanka, 2024-01-11 11:25
Screenshot 2024-01-11 at 15.54.22.png (55.4 KB) Screenshot 2024-01-11 at 15.54.22.png version 9.9.1.8 output Lahiru Madushanka, 2024-01-11 11:25
Actions #1

Updated by Martin Honnen 11 months ago

copy-namespaces="no" helps to ensure in-scope but unused namespaces are not copied, it doesn't remove the namespace an element itself is in. So the result you get from 12.4 is the correct one.

Actions #2

Updated by Michael Kay 11 months ago

Martin is correct: the effect of copy-namespaces="no" is to drop unused namespace declarations, it should never move an existing element into a different namespace.

That raises the question of why it behaved differently in Saxon 9.5. Unfortunately investigating a very old release like that isn't easy.

I have confirmed that the output changed (that is, the bug was fixed) between 9.5.1.8 and 9.5.1.10, that is, between January and May 2015.

I think the most likely explanation is that the change in behaviour was caused by fixing bug #2209.

Actions #3

Updated by Michael Kay 9 months ago

  • Tracker changed from Bug to Support
  • Status changed from New to Closed

Closing: the product is behaving correctly according to the spec,

Please register to edit this issue

Also available in: Atom PDF