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

[Peter V. Gadjokov]

> 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 (;-))

I've read it, but I'll be the first to admit I have a lot more experience
designing and implementing OO APIs than I do dealing with XML. So it's not
hard for me to read the spec and still miss something - that's changing, in
no small part thanks to input from the list. In the interim, you're forced
to read my harebrained ideas (and I don't mean that any more sarcastically
than you take it :)

> getChildAttributes() makes no sense, because an Element can only refer
> to its own attributes. 

Must have been someone else's proposal, it isn't in anything above. I was
talking about sticking with getChild/Children for elements and ditching
content/losing global doc. order. The latter, as Amy Lewis pointed out, is
completely bogus. 

Actually, I went back and re-read the last set of emails and noticed
getChildAttributes in Alex's proposal and my badly quoted +1 -
getChildAttributes is undoubtedly wrong, under any spec. No spec describes
an attribute as a child. This also explains Jason's -50. My mistake, I
quoted more than I meant to above my +1. 

> 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

Under this scheme, we'd stay with getChild[ren] - we stay with using the
term 'child' for elements exclusively. getChildElements is not needed in
that case, addChild would be for Elements only, gives you symmetry with
getChild. As to addContent, I think it's not so cut and dry - what the XML
spec calls content, the Infoset calls the 'children property'. The Infoset
does use (but not define) the term content to mean the same thing but the
explicit property is 'children'. 

> 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.

The current use of getChild is infoset-deviant. I'm fine with most of Alex's
proposal which is different from what we have now but almost completely
infoset compliant. I'm also fine with the the way things are now, perhaps
with the addition of addChild convenience methods (passthrough to
addContent(Element el) that would make the naming symmetrical. As to
getChildElement[s], for all I know, I'm fine with it too. But it would be
nice to see a brief writeup of all relevant methods under that naming scheme
or a reference to a list-archive message that contains it. Alex's point is a
very good one - it's far too confusing to be talking about single method
names. 

> 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.

Agreed. But the interpretation of the spec (and which spec) is what prompted
my other thread. The specs are getting so big and plentiful, chances are
something will be confusing under some spec. 
 
> I'm all for ingenuity, but I'm not for convoluity (word?)

pvg at triptonite:~ jargon convoluity
No matches for "convoluity" at
<http://work.ucsd.edu:5141/cgi-bin/http_webster>
pvg at triptonite:~ webster convoluity
No matches for "convoluity" at <http://www.m-w.com>
No matches for "convoluity" at
<http://work.ucsd.edu:5141/cgi-bin/http_webster> 

But in the spirit of ingenuity, let's declare it a word. 

-pvg