[bugfix] Preserve attribute namespace when copied via enclosed expression (+4 XQTS HEAD)

[joewiz]

Summary

When a namespaced attribute is copied into a direct element constructor via an enclosed expression and the source attribute's prefix conflicts with a binding already declared on the new constructor, eXist silently changed the attribute's namespace URI to match the constructor's binding (or, for two-attribute cases, collapsed both attributes into the same prefix). For example:

let $src := <s xmlns:foo=\"http://example.com/A\" foo:k=\"v\"/>
return <out xmlns:foo=\"http://example.com/B\">{$src/@*}</out>

returned <out xmlns:foo=\"http://example.com/B\" foo:k=\"v\"/> -- attribute k ended up in URI B, not its source URI A.

Spec rule

XQuery 3.1 §3.9.4 (In-scope Namespaces of a Constructed Element):

For each prefix used in the name of the constructed element or in the names of its attributes, a namespace binding must exist. If a namespace binding does not already exist for one of these prefixes, a new namespace binding is created for it. If this would result in a conflict, because it would require two different bindings of the same prefix, then the prefix used in the node name is changed to an arbitrary implementation-dependent prefix that does not cause such a conflict, and a namespace binding is created for this new prefix.

What changed

exist-core/src/main/java/org/exist/dom/memtree/DocumentBuilderReceiver.java

DocumentImpl.copyStartNode dispatches a copied attribute node to receiver.attribute(qname, value). Within an enclosed expression EnclosedExpr disables the receiver's checkNS flag for the duration of the copy, so the attribute was previously added to the MemTree with its original (prefix, URI) QName but no namespace node was emitted on the parent constructor element for that binding. The serializer then resolved the attribute's prefix against the constructor's already-declared xmlns:* and wrote it in the wrong URI.

attribute() now resolves the QName for any namespaced attribute regardless of checkNS:

• If the prefix is already bound to the same URI on the parent element: keep it as-is.
• If the prefix is unbound: declare it.
• If the prefix is bound to a different URI: reuse an existing prefix already mapped to the source URI, or generate a fresh one (XXX, XXX1, ...) and declare it.
• In all cases emit a namespace node onto the parent element. Emission is idempotent against the parent's own element prefix and any xmlns:* nodes already declared on it.

exist-core/src/test/java/org/exist/xquery/ElementConstructorAttrNamespaceTest.java

Three JUnit regression tests covering the inline reproducers for Constr-inscope-3, Constr-inscope-4, and the minimal single-attribute case.

XQTS HEAD before / after

prod-DirElemContent.namespace (133 tests):

	Before	After
Failures	35	31
Constr-inscope-1	FAIL	PASS
Constr-inscope-2	FAIL	PASS
Constr-inscope-3	FAIL	PASS
Constr-inscope-4	FAIL	PASS

No regressions in the rest of the test set.

Test plan

• 3 new JUnit regression tests pass (ElementConstructorAttrNamespaceTest)
• ConstructedNodesTest, ConstructedNodesRecoveryTest, NamespaceUpdateTest, CompAttrConstructorErrorCodeTest, DocumentBuilderReceiverIntegrationTest, XPathQueryTest (150), XQuery3Tests (1011), XIncludeSerializerTest: 1200 tests pass, 0 failures
• W3CXIncludeTestSuite baseline parity (37/183 failures both before and after on develop)
• XQTS HEAD prod-DirElemContent.namespace: -4 failures, 0 regressions
• Codacy PMD clean on the changed file (only pre-existing warnings)

🤖 Generated with Claude Code

[joewiz]

[This response was co-authored with Claude Code. -Joe]

Pushed a follow-up commit (84762a9) addressing the two XQueryTest regressions:

• attributeNamespace
• noNamepaceDefinedForPrefix_1959010

Both were assertEquals on serialized XML strings, asserting on the textual order of xmlns:c and xmlns:d declarations. XQuery 3.1 §2 makes the relative order of namespace nodes that share a parent implementation-dependent, so the new ordering this PR produces is conformant — the assertions were over-specifying. Converted both to DiffBuilder.checkForIdentical() (matching existing XMLUnit 2.x usage in the same file).

No production code changes; the +4 XQTS HEAD lift is preserved.

Full-module mvn test -pl exist-core gate: Tests run: 6736, Failures: 0, Errors: 0, Skipped: 97, BUILD SUCCESS.

[line-o]

@joewiz could you rebase this PR

[reinhapa]

Address Codacy issue: The method 'emitNamespaceNode(String, String)' has an NPath complexity of 240, current threshold is 200

[joewiz]

[This response was co-authored with Claude Code. -Joe]

Rebased + addressed in 792e62279d. Two changes:

1. NPath complexity on emitNamespaceNode — decomposed into three named guards that read like the conditions the method is actually checking:

• isElementParent(doc, parent) — parent is a real element node
• isParentSelfDeclaration(doc, parent, prefix, uri) — the binding is redundant because the parent element name already carries it
• hasExistingPrefixDeclaration(doc, parent, prefix) — scan namespace decls already attached to parent

Top-level method becomes four short guard clauses + the emit call.

2. While I had the file open, a local Codacy run surfaced eight more pre-existing nits that any next review-round would also have caught. Folded them in here to save a round:

• Seven empty SAX-callback method bodies (setDocumentLocator, startCDATA, endCDATA, startDTD, endDTD, startEntity, endEntity, skippedEntity) — one-line "no-op" comment on each explaining why the in-memory builder ignores the event.
• generatePrefix(XQueryContext, String prefix) reassigned its parameter inside a while loop — rewrote as an early-return for the "already supplied" path + a clean candidate-loop using an immutable parameter. Functionally equivalent.

Codacy clean on the file post-refactor. 210 tests pass (XPathQueryTest 150, memtree tests 60), no behaviour changes.

On the pre-push gap: I should have caught the NPath-240 finding before pushing the original commit. The repeated failure mode was running Codacy on net-new files but not on edits to existing ones. Tightened the rule on my side — mandatory pre-push Codacy on every changed Java file — and you should see fewer of these review-cycle-burn nits coming back.