[jdom-interest] More changes

[Jason Hunter]

> > Whoa, that was fast.  You didn't comment on my code.  I'm not saying I
> 
> I read through it, and summed up what I thought was the crux of the
> situation. Sorry ;-)

No problem.  :-)  

> > To answer your questions:
> > 1) It acts only on the first child, just like getChild() does.  This is
> > no more confusing than methods already in the API.
> 
> I'm not sure I agree - it is the first method that combines obtaining
> content with determining the existence of an Element. There is no way to
> tell if an Element doesn't exist and you got defaults, or if the content
> was wrong, and you got defaults, or there was an Element with no content
> (only other Elements) and you got defaults.

(BTW, I think we come to a nice agreement toward the end of this email,
but my requirements laid out here still stand.)

The two possible reasons for failure of getChildContent (bad name
agreed) are that the child doesn't exist or the child has no text
content.  I don't generally care to differentiate between the two most
of the time.  I want to read the value, and if the value doesn't exist
I'll output an error saying "no <param-name> data found" and that covers
both cases well enough.  Or I can optionally specify a sane default
because in specs like Servlet API 2.2 talking of web.xml there are
places where it says things like "if this isn't an integer treat it like
a negative value".  The code I wrote shows how error handling is done.

> This is the very thing we are trying to fix right now with getXXXContent
> and getXXXValue

I'm not sure how I feel about that removal.

> > 2) Yes, you can't use this shortcut for the second child.  But since the
> > use case in places like web.xml is where elements are being used where
> > attributes might, it's not common for there to be two children.
> 
> But that is /always/ the use-case in XML - you can show almost any XML
> document with attributes or elements. I'm just not convinced that this
> is such a compelling use case. 

Reading structured data files isn't a compelling use case for JDOM?

> You are saying right off (by using
> getChildContent(String name)) that you have an expected format for the
> document. Because of that foreknowledge, I can't see this being any
> advantage (albeit making slightly longer code) in functionality, and I
> do think it falls in the category of API bloat.

The code someone needs to write to accomplish this compelling use case
wasn't "slightly longer".  It was exactly double the number of lines. 
That's code bloat.

> > Maybe XPath would be sufficient to handle this; I haven't explored
> > enough there.  But in the near term I would really appreciate
> > functionality like this.  My code examples show that in my opinion.
> 
> Ahhh ... now the real deal. XPath is absolutely the right solution. And
> you taught me not to introduce a method you know you're going to
> deprecate ;-)

OK, I think we can come to agreement because I think XPath could provide
the right general solution to this class of problem.  But before I shut
up about my needs, what do you see as the actual call?  Assuming we have
a completed XPath implementation, could you write the code that would
handle my use case (identical functionality)?

-jh-