> > [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 KayReceived on Wednesday, 22 October 2003 13:04:03 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:43:43 UTC