[jdom-interest] Ideas for API changes

[Amy Lewis]

On Mon, Apr 30, 2001 at 07:16:25PM -0700, Jason Hunter wrote:
>Amy Lewis wrote:
>> *Why* in the name of all the forest gods would you put addContent() on
>> the Node interface?  
>
>I didn't!  Note I wrote Element.addContent(Node) and
>Document.addContent(Node).

My bad.  Please accept apology.

>> Which raises the point that Doctype and Entity are probably not Nodes,
>> either.
>
>They are in Brett's mind.  Seems some people have visions of Node
>dancing in their head, but the visions aren't the same.

In another email, Elliotte suggests discarding Entity.

But yes, there are clearly additional issues with a Node interface, at
the borders.  I think that they're solvable, though, and that they *do*
solve a problem.

I'll add that the applications in which I typically work involve:
1) navigation; I'm +1 on making navigation easier
2) genericity: I often don't care about the nature of the node that I'm
coping with (that's implicit in the navigation that got me here), but I
want its value; I'm +1 on changes that hand me back a generic object
that I can query for value (that's not java.lang.Object)
3) partial processing: module A cares about subset A, module B cares
about subset B, and they may overlap (extend this to many more letters,
however ... the pipelines extend); I'm +1 on changes that allow me to
better target a portion of the document, instead of having to walk
every damned node in the tree to get to where I want
4) mutability: at any point in the pipeline, the document may be
changed, sometimes quite significantly; I'm -1 on changes that make it
difficult for me to do what I need to do (for instance, the
applications we use regularly create and unwrap envelopes, extracting
some child from the root and promoting it, or demoting the root to a
first level child with several siblings)
5) extensibility; I'm +1 on anything that makes it easier for me to
customize the API for my particular circumstances

>> Oh, *give* me the damned knife!  If I cut myself, it's *my* problem!
>
>So you're +1 on removing all well-formedness checking?

argumentam ad absurdam; that was not what I said.  I'm +1 on allowing
subclassers to *fulfill the contract of the Node interface*, which in
JDOM context implicitly includes well-formedness.  See point 5 above. 
This is partly a philosophical issue: is JDOM the be-all and end-all of
XML representations in Java?  If I wanted to extend JDOM to support the
XML Schema specification in detail, by adding a Content subclass for
each defined type, you might well think me mad.  So what?  I would, in
fact, be creating an API on top of JDOM that enforces validity as well
as well-formedness, not breaking well-formedness.

Incidentally, I'm not volunteering to do so.  I think it's borderline
mad; the problem is that there's a project on the horizon that could
usefully do such a thing, and make the pain worthwhile.  *shrug*  Since
there is no content node type *at all* in JDOM at present, it isn't
even worth considering, really, and without a Node interface to unify
subclassing, I can't make one without effectively rewriting the API.

BTW, my last couple of posts took about sixteen hours to go through. 
Problems?

Amy!
-- 
Amelia A. Lewis          alicorn at mindspring.com          amyzing at talsever.com
Never imagine yourself not to be otherwise than what it might appear to others
that what you were or might have been was not otherwise than what you had been
would have appeared to them to be otherwise.                    -- The Duchess