Project

Profile

Help

Bug #4661

Namespace constructor: conflicting default namespaces

Added by Christian Grün 15 days ago. Updated 7 days ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
2020-07-31
Due date:
% Done:

0%

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

Description

The following expression…

declare default element namespace 'ns';
<x>{
  element a { namespace { '' } { 'ns2' } }
}</x>

…yields a result:

<x xmlns="ns"><_0:a xmlns="ns2" xmlns:_0="ns"/></x>

This expression…

<x xmlns='ns'>{
  element a { namespace { '' } { 'ns2' } }
}</x>

…raises an error (XTDE0430). Is that correct?

History

#1 Updated by Michael Kay 14 days ago

As far as I can see XQuery does not cover this situation and Saxon is following the XSLT rules, which do. It's not clear what other action is possible. You can't put the element in a different namespace, you can't give it a prefix bound to the null namespace, so you have to reject the namespace node as invalid.

There might be other outcomes that are consistent with the XQuery spec, but I think what Saxon is doing is reasonable.

#2 Updated by Christian Grün 14 days ago

Thanks for your assessment.

By intuition, I would have expected both expressions to yield the same result. But I didn’t find any clarification on this case in the spec either, and I doubt it will occur in practice anyway.

#3 Updated by Christian Grün 12 days ago

In addition, I noticed that element { ' a ' } {} returns < a />, while I would have expected an error. Considering your proposal in https://github.com/w3c/qtspecs/issues/9, a better alternative might be the normalization of whitespaces.

I can add a test case once we have decided for or against the error.

#4 Updated by Michael Kay 7 days ago

Whatever the phrase "If the atomized value of the name expression is of type xs:string or xs:untypedAtomic, that value is converted to an expanded QName." really means, I would expect any detailed rules to include first stripping whitespace, just as a cast operation does. Saxon is stripping whitespace to do the validation and is then erroneously using the original name as written. The bug (in XPathParser.makeNodeName()) is already fixed on the 10/11 branches, I will patch it now on 9.9 though I don't know if there will be another maintenance release on that branch,

Please register to edit this issue

Also available in: Atom PDF