5631 2008-04-07 15:35:20 +0000 [UPD] rename and namespace inheritance 2011-01-07 11:34:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Update Facility Candidate Recommendation PC Windows XP CLOSED FIXED P2 normal --- 1 mike andrew.eisenberg jim.melton jonathan.robie public-qt-comments oldest_to_newest 19749 0 mike 2008-04-07 15:35:20 +0000 The specification of upd:rename() says (in 1.d and similarly in 2.e) "The namespaces property of $target is modified to include a namespace binding derived from $newName, if this binding did not already exist." Normally, and by default, when we create a namespace binding on an element then the same namespace binding is created on all its children, recursively, unless they carry an explicit redeclaration of that namespace prefix. We don't seem to be doing that here. Is this intentional? I would have thought it made sense to propagate the new namespace binding to descendants, or not, based on the "inherit namespace" option in the static context. 21105 1 mike 2008-07-09 15:14:05 +0000 Further thoughts on possible resolution of this bug can be found at: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jul/0014.html (member-only link) 23230 2 jim.melton 2009-01-23 01:53:36 +0000 In its teleconference of 2009-01-20, the XML Query WG accepted the proposal in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jul/0014.html (member-only link) as the resolution of this bug. We are therefore marking this bug FIXED; because you were present when the solution was adopted (and, indeed, because you proposed the solution), we presume that you agree with that solution and we are therefore also marking the bug CLOSED. 24943 3 jonathan.robie 2009-04-28 10:05:32 +0000 When I attempted to implement this, I realized that http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jul/0014.html presents two different ways to handle the semantics of namespace propagation, and the minutes do not tell me which of these to use: <quote href="http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2008Jul/0014.html"> A difficulty with propagating namespaces is that it could cause new kinds of conflicts, and that the result could depend on the order in which operations on the PUL are applied. For example consider: <a><b/></a> and an update that renames <a> to <p:a xmlns:p="p.uri"> while renaming <b> to <p:b xmlns:p="q.uri"/>. Then if the rename of <a> is done first, the rename of <b> would fail because the <b> element has acquired a conflicting namespace binding for the prefix "p". But if <b> is renamed first, there is no conflict, because the propagation of the namespace binding will (presumably) stop when another binding of the same prefix is encountered. It is possible to solve this problem by doing all propagation of namespaces at the end, after all other update actions have been completed (but before revalidation). This can be done using a similar idea to the way we "mark nodes for revalidation". Wherever we add a namespace binding to an element node, we "mark the namespace binding for propagation", and after step 5 of upd:applyUpdates(), we add: 5.1 For each namespace binding that is marked for propagation, upd:propagate-namespace($element, $prefix, $uri) is invoked, where $element is the element node on which the namespace binding appears, $prefix is the namespace prefix, and $uri is the namespace URI. </quote> Neither my notes nor the minutes tell me whether we decided to adopt this part, marked as "possible" in the proposal. 24944 4 mike 2009-04-28 10:30:42 +0000 Yes, the record does seem to be a little bit unsatisfactory here, in that the proposal uses language that is rather tentative. However, my reading of the decision is that all parts of the proposal were accepted including the parts put forward only tentatively. Specifically, this means: (1) In the following places we have to say that certain namespace bindings are marked for propagation: The places where namespace bindings are marked for propagation are: * on upd:insertBefore and upd:insertAfter all the namespace bindings of parent($target) are marked for propagation * on upd:insertInto, updInsertIntoAsFirst, and upd:insertIntoAsLast, all the namespace bindings of $target are marked for propagation * on upd:insertAttributes, any namespace bindings created in step 3b are marked for propagation * on upd:replaceNode, any namespace bindings created in step 4b are marked for propagation * on upd:rename, any namespace bindings created in step 1d or 2e is marked for propagation (2) We need to add upd:propagateNamespace() as follows: The actual logic of upd:propagate-namespace($element, $prefix, $uri) is: For each element $child among the children of $element that does not have a namespace binding for $prefix, (a) add a namespace binding ($prefix, $uri) to $child (b) call upd:propagate-namespace($child, $prefix, $uri) (3) We add another parameter to upd:applyUpdates, being the copy mode from the static context (as with revalidation mode) (4) after step 5 of upd:applyUpdates(), we add: 5.1 For each namespace binding that is marked for propagation, provided that copyMode is set to "copy", upd:propagate-namespace($element, $prefix, $uri) is invoked, where $element is the element node on which the namespace binding appears, $prefix is the namespace prefix, and $uri is the namespace URI. Michael Kay 43899 5 mike 2011-01-07 11:34:16 +0000 The PR specification appears to implement the changes as listed in comment #4.