[
Lists Home |
Date Index |
Thread Index
]
- From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
- To: xml-dev@ic.ac.uk
- Date: Mon, 28 Sep 1998 12:20:38 -0600
At 06:40 AM 9/28/98, Peter Murray-Rust wrote:
>At 20:47 27/09/98 -0700, Gregory M. Messner wrote:
>>2) We desire to provide an API on the client side which exposes a
simple
>>mechanism for creating and modifying objects.
...
>I think a number of people on XML-DEV have a very similar requirement:
The
>Coins approach, the SUN early release of XML, XXX (Steve Withall) and
>JUMBO. We all want object functionality client-side. The balance
between
>client and server may differ, but we need an element-object API.
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.
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. 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
application/ms-tnef
|