XOM API for Processing XML with Java

[Wolfgang Hoschek <whoschek AT lbl.gov>]

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