[jdom-interest] getChildren() vs getElements()

[Brett McLaughlin]

"Peter V. Gadjokov" wrote:
> 
> > No less daunting than your single paragraph internal debates.  :-)
> >
> 
> Hey at least I'm not invoking Zen or the Quality-Without-A-Name :)
> 
> But point taken, I'll try to make my spewage more brief and structured. What
> I was suggesting was  -
> 
> - Move away from the 'tree-of-everything' model
> - Adopt a 'tree-of-elements' model
> - change the API to reflect this
>         - children/parent stay and make sense and are about Elements
>         - content (as a collection of everything
>         in an element) becomes superfluous and is removed
> - change the implementation to reflect this
>         - less PartialList, more type-specific containers

Has ANYBODY other than Jason and I read the XML specification on this
list? I don't mean that any more sarcastically than you take it (;-)),
but come on. 
getChildAttributes() makes no sense, because an Element can only refer
to its own attributes. 

getChildElements makes perfect sense, because an Element can easily
refer to other elements than its own children.

addChild is horrible, because then getChild would have to return
elements, PIs, comments, etc.

addContent is correct, as the things you are adding are /clearly/
element content

Guys, I am not wed to the naming in the spec. But I am /strongly/
against calling something a "fish" when the spec says a "fish" is
something else entirely. I'd prefer everyone take a deep breath, stop
asking for things the way they want the spec to read, and read XML 1.0.
Then make your proposal, and clearly say when things are spec-deviant.

And I'll repeat - if it's a new name, that's considerable. But if the
spec clearly says a term is one thing, and you propose that term be used
to mean something /different/ than its use in the spec, that's a bad
idea, that's confusing, and I'll -1 it.

I'm all for ingenuity, but I'm not for convoluity (word?)

-Brett

> 
> That's all.
> 
> -pvg
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Brett McLaughlin, Enhydra Strategist
Lutris Technologies, Inc. 
1200 Pacific Avenue, Suite 300 
Santa Cruz, CA 95060 USA 
http://www.lutris.com
http://www.enhydra.org