RE: namespace node implementation

> 
> [despite that this is not strictly xquery, i'll leave the 
> thread where 
> it is ...]

There are very few differences between XQuery and XSLT in this area, and I
use the same code to implement both.
> 
> have you tried an implementation based on a model which 
> interns names?

Yes, I use my own "interning" mechanism for all names. There are very few
string comparisons done at run-time.

It confirmed my 
> conjecture, at least to the extent that the only places where 
> namespace 
> bindings figure in the processing are
> 1. the operator which the standard defines to construct names from a 
> prefix and a local part. whereby the prefix argument could well be 
> supplanted with a namespace name argument, and
> 2. for prefix rebinding when serializing.

(1) sounds like string-to-QName casting; which is still needed. It's needed
quite often in XSLT because there are lots of functions like key() and
decimal-format() that take a lexical QName as an argument. In practice, in
99% of cases, these are supplied as string-literals and can therefore be
resolved at compile time, but for the other 1%, you have to be prepared to
save the namespace context to resolve it at run-time. It's needed far less
often in XQuery, but it can certainly arise with computed element and
attribute constructors.

(2) doesn't require the whole namespace context to be maintained at
run-time. The simplest approach if you want to preserve prefixes is to hold
the prefix in the element or attribute node. (In Saxon I hold the
prefix/uri/localname triple in 32 bits).
> 
> that is, if the parser - or at the latest the compiler, interns names 
> the standard semantics can be achieved by a much simpler processor 
> which observes prefix-namespace bindings on serialization only.

You can't leave everything to serialization time. There is the name()
function to consider, as well as QNames-in-content.

Michael Kay