XOM API for Processing XML with Java

[Mik Lernout <mik AT futurestreet.org>]

Well, I at least tried: I follow your reasoning for the Collections and 
when I slept over it I realized the .iterator() - solution is worse than 
doing nothing at all... I don't like Collections as well, but negating 
it completely seems a little drastic and unnecessary... It would already 
be cool to have easy access to a copy of the array of Elements like in 
the Collections 'toArray()' , you could make it type safe and it would 
be easy to use in a scripting language...

As for the Attributes: read your reply, watched tv, stared at the 
ceiling  and am now fully complying to the standards :-)

PS: And also: when somebody is iterating and an element is removed, it 
will throw a ConcurrentModificationException, as it should...

Elliotte Rusty Harold wrote:

> > Hmm, allow me to disagree :-)
> >
> > I like the type safety of the Nodes and Elements (really enjoyed your 
> > interview on Artima describing that by the way) but why could they 
> > not be implemented at the same time, for example by adding an 
> > iterator() on the Elements and the Nodes-classes, like in the 
> > attachment I send with this mail. It would not alter the type 
> > safetyness and, at the same time, allow access to the list in a 
> > Collections - standard way.
>
> Because the Collections API is ugly as sin, in large part because it 
> does not expose the types of the individual elements; blame the lack 
> of generics for that. Plus it's confusing as hell. What happens when 
> someone's iterating and an element is removed? Adding collections 
> would provide no significant gain, and would make the API considerably 
> more complex.
>
> > As for the Attributes argument: why is there getAttributeCount() and 
> > a getAttribute(int index) if you would only get them by name?
>
>
> Sometimes you need that. It's just relatively rare.
>
> >  I don't see the difference between Elements and Attributes: probably 
> > most people will use the getChildElements(name) and 
> > getAttribute(name), but we still need to provide access to the list 
> > of these items, in a clean way. If you would expose the Attributes 
> > you would bring down the number of methods on Element, standardize to 
> > calling a 'count' a 'size' everywhere and allow for another type safe 
> > "value-ish" object to interface with.
>
>
>
> Elements and attributes are quite different. They are not equivalent. 
> Most significantly, there cannot be more than one attribute with the 
> same name.  getAttribute(name) is guaranteed to return zero or one 
> thing. getChildElements(name) is not.