Skip to Content.
Sympa Menu

xom-interest - [XOM-interest] Re: XOM 1.0d23 Last Call

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Wolfgang Hoschek <whoschek AT lbl.gov>
  • To: xom-interest AT lists.ibiblio.org
  • Subject: [XOM-interest] Re: XOM 1.0d23 Last Call
  • Date: Mon, 09 Feb 2004 13:34:25 -0800

Just my 5 cents on the namespace and hasChildren issues:

One xom design principle is to avoid convenience methods, thereby making it easier to understand and learn in overall.

IMHO all those methods for no-namespace scenarios (as well as the trivial hasChildren()) are just convenience clutter and hence unnessecary.
If the javadoc would make it clear that null or "" as URI are intended for the no-namespace scenario, then to me it is not a burden at all to write
new Element("xyz", null)
instead of
new Element("xyz");

Wolfgang.


On 02/02/2004 11:14 AM, jcowan at reutershealth.com was heard to exclaim:
2) Consider flushing the no-namespace constructors: they save only 3
characters
(plus optional whitespace) over the corresponding namespace constructors.
Trying to let people use a namespaceless subset of XOM really doesn't save
much mental space, I don't think; DOM has these things because Level 1
predates namespaces.
1) Remove no-namespace constructor: see Attribute for rationale.
3) Remove no-namespace versions of getAttribute, getAttributeValue,
getChildElements, getFirstChildElement; see Attribute for rationale.

Perhaps I'm exposing some gross and defiguring ignorance here, but I think
this is a bad idea.

I don't use namespaces in my work, and I would deeply resent having to go
through all of my xml code and add what amounts to a null parameter to each
XOM call. Forcing people to add a namespace *requires* a lot of mental space.

If you can convince me that I *need* namespaces (in code that's worked for a
year without them), then I'd be willing to consider this proposal.
Otherwise, I think it would make XOM less usable, and harder to learn.

--
Dirk Bergstrom dirk at juniper.net






Archive powered by MHonArc 2.6.24.

Top of Page