[
Lists Home |
Date Index |
Thread Index
]
Kevin Jones wrote:
>As I am sure you know neither of the common API models, I mean
>SAX or DOM (in any variant that I am aware of), either
>separately or togeather provide an ideal platform for high
>performance XML processing. While development concerns are not
>the focus here the encoding format is important because it
>determines the functionality available to an application unless
>it is prepared to convert the data to some other format at some
>cost.
>
>For me a successfull encoding would need to be both efficient at
>SAX style replay but also support efficient data access directly
>from its encoded form. Or put another way, solving the
>speed/size issue just for data transmission is only part of the
>battle, the receiving application must also be able to process
>it efficiently which implies in native form. Something of a
>combination of XBIS and esXML might be close assuming that esXML
>meets its claims.
>
>
>
I can certainly see that as a valid issue. It's a much bigger battle,
though, because you're trying to make a pervasive change in the way
developers work with XML. My focus on a transport encoding that's
convertible to and from SAX2 (or XMLPull, or StAX, or DOM, or JDOM, or
dom4j, or XOM, etc., either directly or via SAX2 as an intermediary) has
the benefit that it can be pluggable with essentially no change to the
the vast majority of existing applications. For example, it could be
used for Web services with Apache Axis SOAP (but not JAX-RPC RI, which
uses its own parser), or data binding using JAXB, directly.
- Dennis
--
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
|
