XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

> However without a
> > convincing use case nothing's going to change. To avoid 
> wasting time,
> > the following use cases have been presented and do not convince me:
> >
> > 1. Anything involving binary encodings of XML
> > 2. Anything involving replacing part of XOM
> > 3. Anything involving an unfinished specification
> > 4. Anything theoretical (i.e. just something you've thought of; not
> > something you actually need to do.)

It's worth pointing out that anything that implements XSLT or XQuery on top
of the XOM model (as Saxon does) is going to need to establish the full
namespace context of an element in a number of situations. The obvious
situations are when the user requests it (using the namespace axis or XPath
2.0 functions such as in-scope-prefixes().) Of course these require use-case
justification just as if the user were doing it using XOM interfaces
directly. But the other context is that whenever XSLT or XQuery copies a
subtree rooted at an element, then by default it has to copy all the
in-scope namespaces for that element. The reason for this (apart from simply
because it's in the spec) is that there is no way of knowing which of the
namespaces are actually needed and which aren't. I think that copying a
subtree in XSLT or XQuery is probably quite a common operation, though I
don't have any measurements to back that up. Saxon sometimes creates a
virtual copy, which helps, but this isn't always possible.

You can classify XQuery as an unfinished specification if you like, but XSLT
has been around for a few years...

Michael Kay
http://www.saxonica.com/