Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] Canonicalizer Performance

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <wolfgang.hoschek AT mac.com>
  • To: Michael Kay <mike AT saxonica.com>
  • Cc: 'Elliotte Harold' <elharo AT metalab.unc.edu>, 'John Cowan' <cowan AT ccil.org>, 'xom-interest' <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] Canonicalizer Performance
  • Date: Mon, 28 Aug 2006 13:56:27 -0700

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.





Archive powered by MHonArc 2.6.24.

Top of Page