RE: namespace nodes

> The new section 3.7.4 "Namespace Nodes on Constructed 
> Elements" raises a few (mainly editorial):
> 
>    Implementations may in many cases be able to choose a namespace
>    prefix that is familiar to the user, such as a prefix that is
>    associated with the corresponding namespace URI in either the
>    source document or the query.
> 
> The term "the source document" is not defined and does not 
> seem applicable to XQuery.

It would probably be better to say "a source document". This is only a
non-normative Note; its purpose is to suggest to users and implementors that
it's not unreasonable to expect user-friendly prefixes in a result document,
though it can't be guaranteed. (It occurs to me on re-reading it that
another acceptable strategy would be to select a prefix that is used for the
namespace in the schema).
> 
> Also, presumably there would be namespace nodes in a document 
> constructed from fn:doc or other sources (though that isn't 
> stated), and they would normally be "active".  So this would 
> be referring to to "non-active" (i.e. non-enclosing) 
> namespace declarations, which you probably wouldn't want to 
> use anyway.

The terms "active" and "passive" only refer to namespaces declared in the
query. They are properties of namespaces in the static context, not
properties of namespace nodes in the data model.
> 
> But my main concern is that this is very "operational", and 
> overspecifies the implementation.

It tries to specify the outcome - what namespaces are present in the result
trees produced by the query - without specifying anything about the
implementation. Is your problem with the section as a whole, or with the
non-normative note that you are quoting? Or would you like to see more
variation allowed between implementations in the outcome (the observable
result of the query)?

> Worse, it specifies a needlessly 
> inefficient implementation, since you cannot observe the "namespace 
> nodes attached to an element" anyway.  This may mislead some 
> users and naive implementors.

Namespaces were invented, I suspect, to weed out the naïve implementors from
the rest...

What we have tried to do here is to retain the formalization of namespaces
in terms of namespace nodes in the data model (which is needed to underpin
the continued if deprecated availability of the namespace axis in XPath)
while removing things that constrain the implementation. XSLT processors
have showed considerable creativity in implementing the model in ways that
differ markedly from the way it is formally described, and XQuery processors
have even greater freedom because the identity and parentage of namespace
nodes are no longer exposed to the application.

One feature of the rules we have defined is that the decisions about which
namespaces to add to a constructed element can all be made at compile time.
So I think it is possible to implement it efficiently. The area where
implementations have scope to be clever is in optimizing the two stage
process (create namespace nodes for each element, then eliminate duplicates
while serializing) so that unneeded namespace nodes are never created. As
with other aspects of query optimization, I don't think the spec should
discuss that.

> The terminology also conflicts with the 
> "Functions 
> and Operators" definitions of fn:get-namespace-uri-for-prefix and 
> fn:get-in-scope-namespaces which does not talk about 
> "namespace nodes" 
> but uses the term "in-scope namespaces".

I think we should probably restrict the term "in-scope namespaces" to the
case where we are talking about the static context in XPath/XQuery/XSLT, and
speak in terms of the namespace nodes of an element when we are discussing
the data model. Although the InfoSet speaks of the "in-scope namespaces" of
an element, we don't use this term in describing our data model, and
therefore we probably should avoid using it in F&O. You are right to point
out the inconsistency.

Regards,

Michael Kay

> 
> I'm not sure what the best solution is, but one approach may be to 
> re-cast 3.7.4 to define "in-scope namespaces of an element" 
> rather than 
> "namespace nodes attached to an element".
> -- 
> 	--Per Bothner
> per@bothner.com   http://per.bothner.com/
> 
>