Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XPath Namespace Nodes rethink

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: "Bradley S. Huffman" <hip AT cs.okstate.edu>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XPath Namespace Nodes rethink
  • Date: Sun, 23 Jan 2005 13:26:25 -0600

Elliotte Harold writes:

> Bradley S. Huffman wrote:
>
> > What's the problem with #1? If you offer no public constructors or
> > setters, and don't allow it to be detached what current code would
> > need to be reconsidered?
>
>
> You may be right. Option 1 might make more sense. My initial effort to
> produce a separate XPath package was a big mess because the XPath engine
> used lots of package protected parts. (Again, I really, really wish Java
> had friend functions, but we have to work within the constraints of the
> language.)
>
> Making XPathNamespaceNode a real node would probably make the XPath code
> noticeably simpler. My only real concern is what happens when
> XPathNamespaceNode objects get passed to methods that aren't expecting it.

insertionAllowed() should handle that. Consider what happens when you pass
a Attribute to insertChild? Plus I suggest, at least initially throwing a
exception on detach(), and not having any public constructors
or setters to further ensure it won't adversely effect the rest of the
API.

> I wonder how many such methods are there really? insertChild in
> ParentNode, Document, and Element. XOMTestCase. What else? Maybe some of
> the samples package. Anything else? Too bad javadoc doesn't produce a
> list of all the methods a given object is passed to.

Serialize has one method, and SAXConverter has one.

Brad




Archive powered by MHonArc 2.6.24.

Top of Page