XOM API for Processing XML with Java

[Steve Loughran <steve.loughran AT gmail.com>]

On 1/23/06, Elliotte Harold <elharo AT metalab.unc.edu> wrote:
> Steve Loughran wrote:
>
> > Can I observe that the implementation of getNamespacePrefix(int) and
> > getNamespaceDeclarationCount() are both, well, aggressively suboptimal
> > as they create set structures that are discarded every run. That would
> > make enumerating all the namespaces an O(n*n) kind of process, rather
> > than the more simpler O(n) operation that would appear to be possible.
>
> You may observe that, as it has been observed before. 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.)
>
> There may be use cases that don't get skewered by these rules. Also, use
> cases involving currently unfinished specifications may eventually
> become realistic, practical use cases in the future if not today.

This is something I need to do, which is why I have a class to extract
this by enumerating all namespaces in an element then walking up the
graph to find those of the parent:

http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/cdl/src/org/smartfrog/sfcore/languages/cdl/utils/Namespaces.java?view=markup

This is the obvious way to do it in Xom as it stands today,
accomplished  by using the  getNamespacePrefix(int) operation whose
efficiency I have just commented on. Now while premature optimisation
is the root of much evil, the internals of the namespace llisting is
so wonderfully inefficient that Knuth would probably add a section to
his forthcoming book on it if he looked at the code, shortly before
getting us both thrown out the ACM (you for writing it, me for
knowingly using it and past offences related to SigCHI,  usability and
inappropriate use of the word "findings" without adequate supporting
data :)

My particular need is this: I need to get a list of all currently
visible (prefix,namespace) tuples on an element so that I can then to
my own qname to element mapping, even after the node I was using has
been reparented.

The way xom works, if I move an element around it does remember all
the prefix decls related to nodes and attributes, but it does not do
the same for XSD:qnames in a string. There are obvious reasons for
that which I strongly agree with, the main one being that the xsd
qname abbreviation is abhorration in itself, precisely because of its
relativenes in interpretation. If things like Xpath let you specify
qnames using a fuller notation so that I could go
cdl:ref="{http://example.org}#node"; instead of cdl:ref="prefix:node",
life would be simpler.

Because I need to do this prefix expansion on moved elements, using
the list of prefixes that were in scope at the time the document was
parsed, I have a pressing need to extract the namespace list.

> 3. Anything involving an unfinished specification

First, you need to give me a list of which standards bodies are
considered acceptable. I assume the W3C is, travesties like WS-A
notwithstanding. OASIS? How about the Global Grid Forum
(http://www.ggf.org/) :

http://cvs.sourceforge.net/viewcvs.py/*checkout*/deployment/deployment/doc/cdl/draft-ggf-cddlm-xml-cdl-10.pdf

If I have my implementation compliant (as in passing the
sourceforge-hosted test suite), in two weeks time, then, provided one
other implementation also passes those tests, the draft specification
should be able to transit into the status "standard". And yes, every
implementation will need to cache the (prefix,xmlns) list, it is not
just a quirk of my own implementation.

Like I said, I can do it today, one I have everything extracted from
the node I can use the list elsewhere without caring about how it was
done. So there is no pressing need for a change. At the same time, it
is frustrating that as I step in with the debugger I can see that the
operations I need are there, only package scoped. I don't want to add
stuff to the package as I need to run in signed-jar classloaders, and
I also understand exactly why you dont want to expose stuff
needlessly, as it only increases maintenance costs. Its just that some
of us really do need to get at that list of XMLNS declarations, be it
to cache the list, or to create a javax.xml.namespace.NamespaceContext
implementation.



>
> However so far no one has presented any such cases that felt compelling.
> Until someone proves me wrong by presenting such a use case, I remain
> convinced that iterating over all the namespaces of an element, either
> in-scope or declared, is a very strange thing to want to do and far
> beyond the 80-20 point. Since it is possible to iterate over namespaces
> in XOM, I have no desire to complicate the API just to make it faster.

Easier would be nice. Yes, it is possible for me to do the tree
walking stuff myself, and I have done so, but I also had to invest
time doing that and the tests to validate it.