[jdom-interest] The JDOM Model, Chapter 15 of Processing XML with Java

[Laurent Bihanic]

Elliotte Rusty Harold wrote:
> As to littering the API, I'm not sure Node has to be an interface. It 
> might be simpler as an abstract superclass. No real problem since 
> currently all the classes extend Object anyway. (except CDATA, but also 
> not a problem). The key idea is to have a common base type. Whether that 
> type is an interface or a class is an implementation detail.

Agreed.

>> And just like him, I think useless methods are a bad idea. For 
>> example, how would you implement getName() on Comment or getParent() 
>> on Document?
> 
> As defined by the XPath 1.0 data model; i.e. the empty string and null 
> respectively

Empty strings may be OK in the context of an XSLT stylesheet but a programming 
API is different. There are cases where people need to distinguish between an 
absent value and a actual empty string value.
We already have this discussion about XPath.valueOf: I still think, as a 
programmer, that JDOM should give me the visibility of whether the XPath 
expression matched or not.

XPath is OK when you accept the limitations of its model but I think JDOM lays 
at a lower level than XPath and it should thus give the programmer access to 
finer details of XML documents.
That's why XPath support is a complementary thing, not something that should 
be the (sole) model.

> It looks a *lot* worse to me. Couldn't you do this without exposing 
> those ugly bitfields?  The second option is much preferable, but I still 
> suspect this could be cleaned up a lot.

We can work on that!

Laurent