Re: namespace nodes

Kay, Michael wrote:

(Thanks for your lengthy response!)

>  > 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.

The section seems very "specialized".  What if you have an existing
element node (either from an input document or a previously-constructed
element) that needs to be copied because it is in a content expression?
It would need to get namespace nodes from both the enclosed constructor
(active namespaces), as well as any previously existing namespace nodes.
But the section doesn't cover this, even though it seems like the same 
issue, and that's what is weird to me.

> Is your problem with the section as a whole, or with 
> the non-normative note that you are quoting?

The section as a whole.

> Or would you like to see more variation allowed between implementations
 > in the outcome (the observable result of the query)?

No, I don't think so, though I am concern taht it only discusses
immediately construcxted nodes, not copied nodes, or nodes in source
documents.

It's like if a specification for printf explained in detail how to
format even integers but completely ignored odd integers.

> 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.

You know their existence, but not their prefix or namespace at
compile time.  You have to check for duplications are run-time.
You don't know which prefixes are shadowed by other prefixes.

 > 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.

Fair enough, though I'd add a "Note: Namespace nodes are part
of the data model only; XQuery does not provide any way to get at a
namespace node".

> 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.

Seems reasonable.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Received on Tuesday, 26 August 2003 15:19:35 UTC