XOM API for Processing XML with Java

[John Cowan <cowan AT ccil.org>]

Elliotte Rusty Harold scripsit:

> We could fix this in checkInsertChild like so:

[snip]

> Gaak. That's ugly. I don't like the side effects or throwing the 
> exception here, but I think that should work.
> 
> Can we do the same in checkAttach()? Let's see:

[snip]

> Still ugly, but not significantly different than the checkInsertChild 
> solution.

The difference isn't apparent in your examples, but in fact it's the
child who's going to know what his "natural parent" should be.  So as
a matter of OOD, the code should be in the child class.  

But not only is this code butt-ugly, it's unusable.  When the caller
tries to add an element, it will not only have to trap the XMLException,
but then will have to either look inside the exception or examine the
tree to see whether the element in fact got added (perhaps several
levels down after this happens recursively) or if there has been a complete
failure.  That's intolerable.

Furthermore, making the Right Thing happen is going to depend on whether
the insert method calls checkDetach or checkInsertChild first.  If the
parent has already vetoed the insertion, the child won't get a chance to
do any fixup (or vice versa).

Automatic fixup like this is just too messy.  Go with checkInsertChild and
checkRemoveChild only, and to hell with the cross-package issue; as
you say, typically the parent will know who his children are allowed to be.

> OK. I see what you're trying to do. How badly do you need to do this?
> And are you sure you want to do this? For instance, would your system
> be designed to handle pages of mixed HTML, SVG, and MathML? Would it
> handle HTML embedded in other applications? Would it handle
> well-formed but invalid pages like http://www.cafeaulait.org/ that
> deliberately use non-standard elements such as "today"?

Good points all.  I think what it means is that checkInsertChild
validation shouldn't depend on the class of the child, but only on the
qualified element name of the child.  That way, it's all one whether
you insert a PElement or a plain Element whose element name is html:p.
Of course, this is not something that XOM can enforce, just a convention
for extension packages to interoperate.

In that way, if the package is built around lax validation, it can just
accept elements of other packages as children; if strict validation is
called for, it can use its own validation rules to determine whether
or not to accept them.

-- 
He made the Legislature meet at one-horse       John Cowan
tank-towns out in the alfalfa belt, so that     jcowan AT reutershealth.com
hardly nobody could get there and most of       http://www.reutershealth.com
the leaders would stay home and let him go      http://www.ccil.org/~cowan
to work and do things as he pleased.    --Mencken, Declaration of Independence