Bug #3149: Constructed element node lacks xmlns="" undeclaration - SaxonJS - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #3149

closed

Constructed element node lacks xmlns="" undeclaration

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

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Sprint/Milestone:

Start date:

2017-02-28

Due date:

% Done:

100%

Estimated time:

Applies to JS Branch:

1.0

Fix Committed on JS Branch:

1.0

Fixed in JS Release:

Saxon-JS 1.0.1

SEF Generated with:

Platforms:

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.

Actions

Copy link

Updated by Michael Kay over 7 years 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);
                        });

Actions

Copy link

Updated by Michael Kay over 7 years ago

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

Actions

Copy link

Updated by Michael Kay over 7 years 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.

Actions

Copy link

Updated by Debbie Lockett over 7 years 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.

Actions

Copy link