xml-dev - Re: XML and Objects

[David Brownell <db@Eng.Sun.COM>]

Arnold, Curt wrote:
> 
> Tim Bray wrote:
> >This can/should be built on top of the DOM, right?  -Tim
> 
> If on top of the DOM you mean that you would would completely populate
> the DOM, then build the corresponding objects, then I would tend to
> disagree.  I have had good luck and performance restoring objects from a
> large (>2MB) XML file responding to events from Expat.  If I first built
> an in-memory representation and then processed the information, I don't
> think that I could get nearly the same performance.  I would think an
> object creation and link resolution layer on top of SAX would be
> preferable.

That's one of the reasons that the early/experimental support for such
"XML Beans" in Sun's library features the ability to transform a DOM
tree as it's being built.  See:

    http://www.lists.ic.ac.uk/hypermail/xml-dev/9809/0642.html
    http://www.lists.ic.ac.uk/hypermail/xml-dev/9809/0645.html

DOM (enhanced) is one of the ways to do this sort of stuff.  I've
got a bias towards it since it means One Less API, but there are
those who would rather have a more flexible and lighter weight base
API.  (Committee designs are rarely flexible or light weight!)


> p.s. I've downloaded the Sun XML Early Access, but I can only find
> passing references to XML Beans.  Is there a specific document and/or
> source file that clarify what they mean by XML Beans. 

There's not a lot of stuff written about it; it's a simple (powerful)
idea, so quantity of info isn't the goal.  Also, it's not positioned
as being the "One True Way" -- just one of many ways to use JavaBeans
with XML.  I've seen similar mechanisms used in (un)marshaling data
for at least the last decade.  Many XML systems use similar ideas. 

I'd look at the "XML Beans" section of the package overview (javadoc)
for "com.sun.xml.tree", the "XmlDocumentBuilder" and "ElementNode" 
class docs (in that package), and the "GUI Demo", which uses two
different kinds of beans on the same document (well, same DTD anyway)
to display differently using the Swing JTree facility.  (And yet they
still write themselves out as normal XML text, without losing anything
except the DTD info which SAX discards.)

Of course, there are other ways to use this facility than to model data
for a rendering engine.  The javadocs for the DOM classes were done
with such beans (from XML sources).  And it's a good way to get started
on an XSL implementation.
 

>	 The two
> alternative interpretation of the term that I have contemplated are:
> 
> 1. Java Beans that modify the behavior of the parser
> 2. A serialization mechanism for Java Beans

I actually think the _parser_ should stick exclusively to XML 1.0
behaviour.  But you may be thinking of more than what, say, SAX does;
in my book, building a DOM tree is not a function of the parser.

There are quite a few ways of using beans and XML.  I talked with one
company that had identified seven different ways!  On XML-Dev I've
counted at least four (and wasn't trying hard ;-) and they mostly
come down to different ways to have the parser interact with code
to produce in-memory data structures, and then have those in-memory
data structures generate XML text.

In a separate note I sketched a "serialization" mechanism that didn't
rely on DOM at all ... but uses a specific DTD.  The current XML Beans
stuff can use an arbitrary DTD/Schema ... but relies on DOM for its
in-memory representation.  (Perhaps these two correspond to the options
you listed above.)

Other options involve dispatching some of the parsing events to the
beans (both SAXON and COINS do this now) rather than expecting the
beans to interpose on appendChild.  And there are many more options.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)