This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The reference result for the namespace-errors-q16 test adds a namespace declaration attribute (xmlns="") to un-declare the defaule element namespace binding. This attribute is added in the <PhD> node. However, it could also be added on the parent of that node. Specifically, the attached file is also a valid result.
Created attachment 912 [details] alternative result for test namespace-errors-q16
Please note for reference that this is related to bug #9432 and bug #9312.
Personal response: I think this bug is invalid - that is, the proposed alternative result is not a legitimate result. (However, it's difficult to be definitive until we see the changed wording introduced as a result of the resolution of bug #9432). propagate-namespace() adds a namespace binding (prefix, uri) to all child elements that do not already have a binding for that prefix, and then calls propagate namespace on that child element so it propagates down the tree. The effect of bug 9312/9432 is to extend the meaning of "do not already have a binding for that prefix" so that elements whose name is unprefixed are considered for this purpose to have a binding for the prefix "" even if it is a binding to no namespace. So in this case the namespace binding ("", "http://www.example.com/test") must be propagated to the univ:lab element, and must not be propagated to the PhD element. The proposed alternative result has xmlns="" on the univ:lab element, which means the namespace binding ("", "http://www.example.com/test") has not been propagated to this element, as the [yet to be written] spec requires. Michael Kay Saxonica
It looks as if my comment #3 may have been based on an incorrect recollection of how we decided to resolve bug #9432. The decision on that bug is recorded in the Minutes of the Oxford F2F meeting: the decision recorded there was not to propagate the binding ("", "xyz"), whereas my recollection was that it should be propagated, but only so far as an element whose name is unprefixed.
Given comment #4, what I reported here as a valid alternative result is actually the only valid result, and the current result in XQUTS is wrong. Right?
Yes. I'd prefer to wait until I see final text for the bug #9432 resolution, but from today's discussion it's looking as if your proposed result for namespace-errors-q16 will be the only acceptable result.
The final text for the Bug #9432 has been entered. I have changed the expected result of this test case to the alternative that has been provided, as was suggested in comment #5. Markos, please close this bug report if you agree with this resolution.