XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

> Wolfgang Hoschek wrote:
>
>
> > How would an external XPath impl (without access to XOM's private 
> > backdoors) create an XPathNamespaceNode? I guess it can't, which 
> > suggests the design is rather limited.
>
>
> It can be done but it's a hack. Just create a document with the 
> appropriate namespaces, and then use an XPath expression like 
> //namespace::node() to grab them. This is how the unit tests for this 
> functionality are written.

"Just"? If one develops an external XPath impl one has to parse and run 
another XPath query over another XPath impl to get hold of a namespace 
node? Feels like "security through obscurity", or perhaps like throwing 
sticks between the legs of other folks. By all means, at least you 
could make the constructor protected so one could subclass it in an 
internal private subclass, to be able to use the constructor.

> If someone discovers a compelling use case for creating these, I can 
> expose the constructor; but if not I'd rather keep the constructors 
> package protected. The smaller I can keep the public API the better. 
> YAGNI.

One clear use case is to enable other XPath impls to return a namespace 
node.

> I'm also afraid that if I expose public constructors, programmers will 
> expect to be able to add these nodes to elements. I'm already a little 
> worried that people (JDOM programmers especially) will be looking for 
> the public constructors rather than looking for the write methods in 
> Element.

Yes, to support 0.01% of use cases, we pay the prize of having an ugly 
conceptual misfit, no matter how we juggle it.