XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Randall R Schulz wrote:
> Elliotte,
>
> On Tuesday 29 May 2007 18:17, Elliotte Harold wrote:
> > Cass Costello wrote:
> > > What are the disadvantages you see, Elliotte?
> > Incompatibility with everyone still on 1.4 is the big problem.
>
> Java 5 / 1.5 was released by Sun two years and eight months ago today. 
> We're very far out from that release. Compatibility with 1.4 is a 
> dinosaur problem, and it is highly dubious whether institutions that 
> cannot find a way to migrate to 1.5 should dominate the decisions of 
> library providers.

I'd estimate at least half of the market is still on 1.4, maybe more. No 
way I'm throwing that away.

If there were real benefits to moving to 1.5, I'd consider it a little 
more, but I don't see any compelling gains to be made here.

> > It would also needlessly duplicate functionality in the API. In XOM
> > there's exactly one way to do it, and Iterator isn't it. Use a
> > NodeList.
> >
> > Finally, you'd have to figure out what to do about the remove()
> > operation. I don't think there's a good answer for that. 
>
> There's no obligation to implement remove(). You can throw an 
> OperationNotSupportedException while remaining compliant with the API 
> specification. See <http://java.sun.com/j2se/1.5.0/docs/api/> for 
> confirmation.

UnsupportedOperationException is an ugly hack that should never have 
been allowed in the Collections API. It is a nasty wart on Java, and a 
one reason I don't want to expose the Collections API in my API at all.

Implementing remove is Scylla. Not implementing it is Charybdis. Neither 
option is acceptable. I choose for XOM to sail a different route 
completely.

> > XOM quite deliberately does not expose overly generic collections
> > APIs that don't perfectly fit the problem space. I don't intend to
> > start now.
>
> Iteration over interior nodes does not "perfectly fit" an object model 
> that is strictly tree structured? That's hard to accept or defend.

That's not the problem I alluded to. The real problem comes down to the 
return type of next() and unreified generics.

--
Elliotte Rusty Harold  elharo AT metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/