XOM API for Processing XML with Java

[Wolfgang Hoschek <wolfgang.hoschek AT mac.com>]

On Aug 28, 2006, at 1:14 PM, Michael Kay wrote:

> > For example, changing
> > the NamePool from a fixed hash table to a form of dynamically
> > resizable hash table (or having it overflow into a dynamic
> > table for the pathologic case) may or may not fall into that
> > category, I don't know.
>
> The basic design assumption behind Saxon's NamePool (sorry this has  
> gone
> rather off-topic) is that it's possible to encode the expanded name  
> of a
> node (URI plus local part) as a 32 bit integer, and a bonus is that  
> there
> are enough bits left over to represent the prefix as well. I've been
> pleasantly surprised how well this has proved to handle some pretty
> pathological cases, like the 15000-strong XQuery test suite. If I  
> had one
> user a month hitting the limit, then I'd raise it to 64 bits; but  
> if it's
> one user every five years, then I won't. (It is possible to  
> partition the
> workload to use multiple NamePools, but even that is something that  
> I think
> very few users have ever done.)
>
> Michael Kay

Ok. You might still consider the most trivial fix: On overflow, have  
saxon simply change the prefix to one that's already been bound to  
the same URI, and continue as normal. This would continue to maintain  
prefixes "as is" for human readability, except for the pathologic  
case, which would actually (arguably?) become somewhat more readable  
by reducing the number of distinct prefixes.

This would be perfectly legal from an XML viewpoint (URI's matter,  
not prefixes), and is still better than erroring out. As a benefitial  
side-effect, it would also bound time and space efficiency.

Wolfgang.