This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 9312 - id-rename-expr-035 should expect error XUDY0023
Summary: id-rename-expr-035 should expect error XUDY0023
Status: VERIFIED FIXED
Alias: None
Product: XQuery Update Facility Test Suite
Classification: Unclassified
Component: XQuery Update Facility Test Suite (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-24 23:23 UTC by Josh Spiegel
Modified: 2010-05-24 21:01 UTC (History)
5 users (show)

See Also:


Attachments

Description Josh Spiegel 2010-03-24 23:23:14 UTC
As test id-rename-expr-035 renames an element, bullet 2. a. of section 2.4.4 applies:

"If the namespace binding of $QName conflicts with any namespace binding in the namespaces property of $target, a dynamic error is raised [err:XUDY0023]."

In this case, $QName has an implied binding of ""="http://www.gym.com" which conflicts with the the default namespace.
Comment 1 Michael Kay 2010-04-01 08:29:09 UTC
I think the test is correct as written.

I think the objection appears to be based on a notion that the element being renamed has an existing namespace binding (""=""), that is, binding the null prefix to the null namespace. There is no such binding in the data model: a prefix is either bound to an actual namespace, or it is not bound at all.

See XDM section 3.3.3: For every element node whose name has no prefix, the element must have a a binding for the empty prefix to the namespace URI of the element name, or must have no binding for the empty prefix in the case where the name of the element has no namespace URI.
Comment 2 Josh Spiegel 2010-04-02 13:56:01 UTC
You are right, I did not know that ""="" is not in the namespaces property.   id-rename-expr-035 is correct.  

However, then it seems namespace-errors-q16 is incorrect.  The test creates a similar situation but instead expects error XUDY0023.  

Also, I believe there may be a problem in the definition of upd:propagateNamespaces when propagating a default namespace.  Consider the following example:

declare copy-namespaces preserve, inherit;
copy $a := <a><b/></a>
modify rename node $a as QName("foo", "a")
return $a

In this example, ""="foo" will be propagated to element <b/> as <b/> does not have a binding for prefix "".  In this situation, it would be necessary to change the expanded QName of <b/> to have the new uri "foo" during propagation.   For another example, consider test id-rename-expr-035.  The user really only needs to rename the root node to achieve the same effect.  Possibly a default namespace should not be allowed to propagate in such cases.  
Comment 3 Michael Kay 2010-04-05 12:54:24 UTC
I agree with Josh (comment #2) on both counts.

(a) it seems namespace-errors-q16 is incorrect

(b) a namespace binding ""="x" should not be propagated to an element that assumes the "implicit" namespace binding xmlns="".

There's a close analogy here with XSLT bug 5857, whereby we changed the rules so that namespace inheritance in xsl:copy-of does not apply to the default namespace; bug 6517 against XQuery is in the same area, but was found not to be a problem after all.
Comment 4 Josh Spiegel 2010-04-06 15:54:43 UTC
I don't know what the bug etiquette in this system is yet so please correct me if any of this is inappropriate.  Here is what I did:

(1) I left this bug open and assigned it to Andrew to track the issue with test namespace-errors-q16 (I think he is the author).  

(2) I added Michael in the CC list of this bug

(3) I created a new bug 9432 to track the issue with upd:propagateNamespaces.  I updated the CC list of this new bug to be the same as this bug.
Comment 5 zhen hua liu 2010-04-07 21:45:55 UTC
yes, namespace-errors-q16 is incorrect, it should go through without errors.
id-rename-expr-035 is correct. This is how my implementation result is.
Comment 6 Michael Kay 2010-04-08 18:17:45 UTC
I have corrected test namespace-errors-q16.
Comment 7 zhen hua liu 2010-04-08 22:42:08 UTC
i have 'cvs synch' your latest change of namespace-errors-q16 and tested my
implementation. It seems to be fine except one thing, in the
result file namespace-errors-q16.xml

there is xmlns="" for <PhD> element as shown below:

 <PhD xmlns="" name="Julia" advisor="r1"/> 

Why there is this extra xmlns="" here ?
Comment 8 Michael Kay 2010-04-08 22:55:17 UTC
>Why there is this extra xmlns="" here ?

Because the PhD element has not been renamed; it is still in no namespace, as it was in the original document. The serializer needs to add this namespace undeclaration to ensure that the element is not moved into the namespace http://www.example.com/test which is now the default.
Comment 9 Josh Spiegel 2010-04-12 19:54:35 UTC
Could you please add an XQueryX version for "namespace-errors-q16-test.xq"?  I would do it for you but I don't have CVS powers.  Thanks.
Comment 10 Michael Kay 2010-04-13 14:52:32 UTC
Re comment #9, I believe Andrew Eisenberg generates the XQueryX version of the tests.
Comment 11 Andrew Eisenberg 2010-04-13 20:27:58 UTC
I've just added namespace-errors-q16-test.xq to CVS.
Comment 12 Josh Spiegel 2010-04-14 22:07:58 UTC
Thanks!
Comment 13 Andrew Eisenberg 2010-05-24 21:01:17 UTC
Comment #6 reported a change to the result of test case namespace-errors-q16. The WG discussed this change at its meeting on May 18 and agreed with it.

To clarify the issue that was raised by this test case, the WG will add both an example and a note to section 2.4.4, Rename, as follows:


Example:

o Rename the root element of bib.xml. 

rename node fn:doc("bib.xml")/books
as fn:QName('http://www.example.com/bib', 'books')


Note:

A rename expression may replace the name of element node that is in no namespace with a QName that has a namespace URI and local name, but no prefix (as shown in one of the examples above). No conflcit in namespace bindings arises during the execution of this expression. The namespaces property of such an element node does not contain a namespace binding with a prefix that is the empty string.