Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XPathContext and lookups

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Steve Loughran <steve.loughran AT gmail.com>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XPathContext and lookups
  • Date: Sat, 15 Apr 2006 15:08:08 -0400

Steve Loughran wrote:


the specs use consistent xml prefixes for namespaces, and so I have a
helper XPathContext that knows all the mappings, it goes hand in hand
with some resolver thing for Xerces that maps URIs to local resources.
But what I cant do is go from an XPathContext to a URI, because that
is not allowed.


So what you need is a single method like this:

public void lookup(String prefix)

This would return null if the context doesn't have a mapping for the requested prefix? Is that all you need?

I understand. But right now you are exposing stuff at package scope
because you have a clear need at the stuff yourself. That's a sign of
a need (yours) that isnt open to others (me)

Data encapsulation is a key pillar of object oriented programming. One should expect that any class or collection of classes will have private parts that are not accessible to the outside world. There are programmers who argue that nothing should be private; everything should be accessible. I just don;t happen to be one of those extremists.

FWIW, there is no such lookup method in XOM now. It's not that I've kept it to myself. It just doesn't exist. The relevant functionality is off in Jaxen. Adding it requires new code, not just marking an existing method public.

It would be trivial of me to place some stuff in at the same scope, say
class XPathContext2 extends XPatchContext
to access the stuff. so you are left with an conundrum: is
maintainability of an application made worse by having a public API
extended, or by having random people adding new classes into the
nu.xom package then publicly redistributing such extensions in their
own open source applications?

Not as trivial as you might think. XOM takes some steps to prevent precisely that. I'm not sure you can add anything to XOM short of forking the code base as Wolfgang has done.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




Archive powered by MHonArc 2.6.24.

Top of Page