This issue was listed in the release notes; as Don noted, easily
fixed.
> 2. getElementsByTagName is not efficient.
Or rather, actually _using_ the result can cost. "Liveness" for
this stuff wasn't universally liked, since the indices are not
stable. (Two calls to item[i] can return different values.)
This is another case of an optimization that could be kicked in
sometime if it matters. There is a fast alternative available.
> 3. Output needs more design work.
>
> One needs to subclass to override output and there is no built in support
> for conversion to other formats. For example, you can not write out a DOM
> Document as HTML without some serious patching or overriding.
Actually, it's easy to write out a DOM document as HTML if you
have a bean to address the different handling of EMPTY tags (for
the "HR", "BR", etc) in HTML. We've had plenty of cause to do
so ... ;-)
There's nothing preventing writing out in any format whatever,
though the write(Writer) method on all nodes could clearly be
renamed to be more suggestive of writing XML !!
> 4. XML Bean concept is a little disappointing for what it does.
>
> I am afraid I can not go into details about this due to Docuverse's own work
> in this area but Sun needs to broaden their view of what a bean is.
Sun has some very broad notions of what beans are; we did coin
the term, and do have ongoing work in that area! THIS kind of
bean was only there to address a common solution to a common
problem. As other discussion has noted, there are quite a few
ways to use Beans with XML. We're open to suggestions.
- Dave