#3 Add some prim. constraint checks to lite

Hi Marc.

Thanks for fixing my bug submission over at:
https://sourceforge.net/tracker/?
func=detail&atid=104144&aid=529590&group_id=4144

I have a couple of little additions to lite-XMLElement
that I find very useful. If you're interested, I can
post them here to patch.

Basically they look a bit like:

getRequiredXXXAtribute (throws if no such attribute,
rather than silently returning null...very helpful,
even if not for much more than debugging documents and
making intent clearer in client code)

XMLElement getOneAndOnlyChild(tag) (!throws iff there
is precisely one child with name == tag, which is
returned in this case)

XMLElement getUniqueChild(tag) (throws if exists >1
one child with name == tag, else returns the child or
null, if !exists)

XMLElement getRequiredUniqueChild(tag) (!throws iff
exists one and only one chuild with name == tag, which
is returned in this case)

Vector getAnyChildren(tag) (returns a possibly empty
enumeration over any children with name == tag)

Vector getAnyChildrenExclusive(tag) (throws if exists
children with name != tag, else returns a possibly
empty enumeration over any children with name == tag)

Vector getSomeChildren(tag) (throws if !exists
children with name == tag, else returns Enumeration of
just children with name == tag)

Vector getSomeChildrenExclusive(tag) (throws if exists
children with name != tag and/or no children with name
== tag, else returns garanteed non-empty Enumeration
of children with name == tag)

Essentially, all of these child access methods are
just convenience methods backed by one general purpose
child access method:

Vector getChildren(
String tagToGet,
int minCount,
int maxCount,
boolean exclusive)

For instance, getOneAndOnlyChild(tag) is really just
getChildren(tag,1,1,true).

I have found that the code for these additional
methods raises the final, compiled/compressed size of
the class only very slighly (degugging and -O turned
off), by ~ 500 bytes, while greatly adding to the
functionality of the class, I think.

Indeed, they have saved me either masses of client
code or inefficient operation over large docuemnts,
using a helper class that first must externalize *all*
of the children before doing the the checking and
filtering. Having to use a helper class or repeating
support for such features ad-hoc in client code just
increases the final total distribution size of any
code written around lite (each class has a fixed
overhead that has very little to do with the amount of
code in it, typically around 3-400 bytes for an empty
class), requires more intermediate allocation and thus
garbage collection, an simply makes life more
complicated and frustrating.

Just let me know if you would like me to post the
patch (of course, you could probably write this
yourself in < 1/2 hour)

Cheers,
Campbell

PS

I'm over at hsqldb...the metadata guy. I just
finished the first working iteration of an ultra-lite
awt/xml appbuilder framework, aimed at simplifying
constrution of tools using the hsqldb Grid and Tree
controls, as well as a few of my own additions, such
as an awt/jdk 1.1.x compliant split panel control,
high quality mouse-over image buttons, an awt
compliant tooltip manager, etc, as well as a very
simplified and scaled down DTD for building up Models,
Views, and Controllers.

Thanks for lite...it fits the bill perfectly for tools
that may end up in applets, or simply where there is
no need top be carrying around an extra MB (or more)
just for the limited XML funtionality required in some
highly targeted case.

I have found lite invaluable, for instance, as a kit
to build XSQL schema via JDBC, for tree display and
for file export from org.hsqldb.util.DatabasManager.
Before I found lite, I was building the tree
directly. Now I have a very nice helper class that
takes any XMLElement and displays it in the tree
control. Super nice to have around, at 6-7K.