Re: namespace node implementation

On Wednesday, Oct 22, 2003, at 19:03 Europe/Berlin, Kay, Michael wrote:

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

as one would expect.

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

wait a minute. 99% of the expression can be constant-folded by the 
compiler - at the latest.
those which combine variable values are deprecated if they combine a 
prefix and local part - or has sentiment on this changed in the interim 
- and could be replaced with operations which combined uri and local 
part.

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

and the saxon experience confirms my observation.
[you may have observed a similar approach in the examples i posted.
> ? (describe (name $a))
> Symbol: ||::\a
> INTERNAL in package: #<Package "">
> Print name: "a"
> Value: #<Unbound>
> Function: #<Unbound>
> Plist: (:PREFIX "")
which is also "held" 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.
>

yet there remains some implacable need to keep the bindings around.
> You can't leave everything to serialization time. There is the name() 
> function to consider,
the name function is, as noted above, to be deprecated to the extent 
that it depend on namespace bindings
>  as well as QNames-in-content.
an QNames-in-context can be constant folded 99% of the time and 
re-expressed as (uri x local-part) combinations 100% of the time.

how does this justify all of the machinery which is required to afford 
namespace bindings indefinite extent? especially when it cannot be 
guaranteed to have the intended effect? all that is necessary is for 
someone to use an unexpected prefix and all is for naught.

...

Received on Wednesday, 22 October 2003 14:49:40 UTC