Project

Profile

Help

Bug #3149

Constructed element node lacks xmlns="" undeclaration

Added by Michael Kay over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Assignee:
Sprint/Milestone:
-
Start date:
2017-02-28
Due date:
% Done:

100%

Applies to JS Branch:
1.0
Fix Committed on JS Branch:
1.0
Fixed in JS Release:
SEF Generated with:
Company:
-
Contact person:
-
Additional contact persons:
-

Description

If an element node in no namespace is attached as a child to an element node that has a default namespace, then the child element ends up in the same namespace as its parent, because no xmlns="" undeclaration is created.

A number of XSLT 3.0 test cases demonstrate this, eg, namespace-0801.

History

#1 Updated by Michael Kay over 1 year ago

Provisionally fixed in DomUtils.copyItem by expanding the relevant code that recursively copies and attaches child elements to read:

                        Axis.child(item).forEachItem(function (child) {
                            var newChild = DomUtils.copyItem(child, context, flags);
                            if (newChild.nodeType == DomUtils.ELEMENT_NODE &&
                                     DomUtils.nameOfNode(newChild).uri == "" && nodeName.uri != "") {
                                DomUtils.declareNS(newChild, "", "");
                            }
                            newNode.appendChild(newChild);
                        });

#2 Updated by Michael Kay over 1 year ago

Unfortunately this change causes regression in other test cases, e.g. namespace-2201, wherein it adds an xmlns="" undeclaration where it shouldn't.

#3 Updated by Michael Kay over 1 year ago

namespace-2201 was working because two bugs cancelled each other out.

There is a separate bug whereby xsl:element with a name attribute that is an unprefixed NCName, and no namespace attribute, creates an element in no namespace, not in the namespace defined by a containing default namespace declaration in the stylesheet.

#4 Updated by Debbie Lockett about 1 year ago

  • Status changed from New to Resolved

I'm not quite sure where we got to with this bug a couple of months ago. I have not seen failures for namespace-2201, but I did have a number of new failures in the namespace test set, following code changes around this time.

On 09/03/2017 the way the result of a test was handled by our test driver was changed - to use the serialized form: Expr.serialize(Iter.Singleton(options.principalResult))

However the serializer dropped namespace undeclarations. This has now been fixed (by adding the domutils.hasNamespaceUndeclaration method, and using this in the domutils.xmlToString method).

I have also made a change within Expr.makeComplexContent append to correctly add namespace undeclarations to the child before appending to the parent.

I believe this fixes the bugs: all -s:element tests now pass, and all but 3 -s:namespace tests pass.

#5 Updated by Debbie Lockett about 1 year ago

  • Applies to JS Branch 1.0 added
  • Fix Committed on JS Branch 1.0 added

#6 Updated by Debbie Lockett about 1 year ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in JS Release set to Saxon-JS 1.0.1

Bug fix applied in Saxon-JS 1.0.1 maintenance release.

Please register to edit this issue

Also available in: Atom PDF Tracking page