Right now the Sun STAX impl is decidedly buggy compared to xerces SAX
(and it's not faster either). The most complete, reliable and
efficient STAX impl seems to be woodstox.
Wolfgang.
On Dec 15, 2005, at 7:22 PM, Yonik Seeley wrote:
Agreed, that is a significant downside.
StAX is included in Java 6, but that doesn't help too much given the
Java 1.4 req.
-Yonik
On 12/15/05, Wolfgang Hoschek <[EMAIL PROTECTED]> wrote:
STAX would probably make coding easier, but unfortunately complicates
the packaging side: one must ship at least two additional external
jars (stax interfaces and impl) for it to become usable. Plus, STAX
is quite underspecified (I wrote a STAX parser + serializer impl
lately), so there's room for runtime suprises with different impls.
The primary advantage of SAX is that everything is included in JDK >=
1.4, and that impls tend to be more mature. SAX bottom line: more
hassle early on, less hassle later.
Wolfgang.
On Dec 15, 2005, at 5:47 PM, Yonik Seeley wrote:
On 12/15/05, markharw00d <[EMAIL PROTECTED]> wrote:
At this stage I am more interested in feedback on parser design/
approach
Excellent idea.
While SAX is fast, I've found callback interfaces more difficult to
deal with while generating nested object graphs... it normally
requires one to maintain state in stack(s).
Have you considered a pull-parser like StAX or XPP? They are as
fast
as SAX, and allow you to ask for the next XML event you are
interested
in, eliminating the need to keep track of where you are by other
means
(the place in your own code and normal variables do that). It
normally turns into much more natural code.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
