[Bug 3849] [XQuery] Copied nodes and in-scope namespaces

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3849





------- Comment #2 from hrennau@yahoo.de  2006-10-22 01:11 -------
Thank you very much for the detailed analysis and discussion! You explained how
a change in the treatment of enclosed expressions would put fundamental design
aims at stake. This shed new light on the matter; so my fresh understanding is
as follows: 

(a) on first glance only those nodes of the expression result need to be
actually copied – rather than taken as is and simply attached to their new
parent – which existed prior to the expression evaluation (typically: nodes of
an input document); (b) however, this amounts to treating the nodes differently
according to information not contained in static/dynamic context and node
properties, thus braking a key principle. Bottom line: unconditional copying is
inevitable, even though it has an effect on in-scope namespaces which may be
regarded as undesirable. (I would appreciate it if you correct this view,
should it be wrong.)

At any rate, the real issue is, as you pointed out, fine-grained control of the
namespaces policy. It is a pity that your proposal was not accepted. I simply
cannot understand that it was argued against as making things more complicated.
On the contrary, it would make things simple, whereas now they are
mind-boggling. This view is based on the assumption that the real intent of
introducing the copy-namespaces mode is controlling the namespaces in document
fragments indeed copied from existing sources, and that the effect on nodes
constructed anew within constructors is often (to say the least) a side-effect,
rather than intended. Of course query results can be quite complex, containing
as well fragments copied from input, as parts constructed in the query. So when
the need arises to control the in-scope namespaces in a copied fragment, how to
protect the constructed part of the result from the side effects? If, say, a
constructed fragment has to be output only on the first of the month, it
inevitably slips into an enclosed expresson and suffers from settings meant for
a copied fragment. With fine-grained control, everything is simple: set the
usual default settings in the prolog and wrap the copying region in a
“redeclare-copy-namespaces” expression. Such a redeclaration expression would
be perfectly analogous to Ordered / Unordered expressions: simply delimiting a
query region with a changed setting. I cannot imagine that any user would
suffer any inconvenience: like the Ordered expression, he uses it, or ignores
it.

(However, even better than introducing a special redeclare-copy-namespaces
expression would be a general reset-static-context expression, which could
change any combination of settings controlled by the prolog Setters (production
rule 7). This approach would solve the problem of properly nesting query
regions with different settings. The introduction of such an expression could
be smoothed by defining any single resettable mode as optional feature. But of
course these musings refer to a future version of XQuery.)

Finally, I do not agree that a clarifying note concerning the scope of the
copy-namespaces declaration is superfluous. You are right in this: the present
text is absolutely clear and unambiguous. But the real problem is not difficult
reading of a paragraph, as you suggest: the problem is that right understanding
requires to link strewn information together in a conscious act whereas a
suggestive term seems to make such an effort unnecessary. Think of a computed
element constructor. Everybody, I suppose, looks at it as nothing else than a
syntactical alternative to a direct constructor, required in the special case
that the element name has to be computed. Most easily it is overlooked that the
mere syntax (!) enforces any child element node to be a copied node. And this
state of affairs is only detected when following a link. Please remember the
fact that the specification is a vital reference for developpers, because
hardly any textbook on XQuery is new enough to be a reliable source of
informaton. The developper looks up paragrah 4.9 and more likely than not
understands “an existing node copied by an element constructor” as nodes copied
from input. This error can even be found in an excellent XQuery textbook. I
suggest a short note in Section 4.9:

“Note:  It is important to be aware that the copy-namespaces mode applies not
only to nodes copied from external sources, but as well to nodes constructed
within enclosed expressions in the content of element or document constructors.
By implication, the mode applies to any descendants of computed element nodes
and of document nodes.”

Or something similar. However, should you reject my proposal also after my new
arguments, I will accept your decision.

Hans-Juergen Rennau

PS: At any rate, the definition of “copy-namespaces declaration” and
“copy-namespaces mode” should be corrected. Instead of “copied by an element
constructor” they should read: “copied by an element constructor or by a
document constructor”.

Received on Sunday, 22 October 2006 01:11:40 UTC