You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Will Dickson <wr...@glaurung.demon.co.uk> on 2000/05/18 14:54:07 UTC

FAQ request: 1.0.4 RevalidatingDOMParser

It would be useful to have an entry in the build FAQ pointing out that
RevalidatingDOMParser is broken in 1.0.4 and won't build. I realise
that developers using the standard build mechanism aren't affected,
but developers with IDE's get bitten.

As an OT aside (and a newbie one at that!) can anybody offer me some
advice? My project intends to use XML as the basis of an open request
/ response protocol to allow various front-end and middle-tier
processes to communicate with our server. Thus we'll be dealing with a
large number of rather small XML documents in as near to real time as
possible, so scalability doesn't matter but performance is critical.
We have decided that DTD's are nasty, and won't be using them,
although we may retrofit XML schemas when they stabilise.

Firstly, is XML even appropriate for this kind of exchange? We like it
because it's human-readable which will make it easy for third-party
developers to talk to the server; this is important to our business
model. But can we support the parse overhead?

Secondly, should we use DOM or SAX? I incline towards SAX, since using
DOM to build the rather detailed Document, only to then transcribe
bits of it into a single problem-domain request object and throw the
DOM tree away, seems wasteful. OTOH this probably means writing more
code.

Any comments?

TIA,

Will Dickson.



Re: FAQ request: 1.0.4 RevalidatingDOMParser

Posted by Baq Haidri <bh...@inktomi.com>.
Though I can't commit on whether or not XML would be appropriate
for the kind of data exchange you're doing, I can recommend that you
use SAX, especially for the small file sizes you will be handling.  It's
fast, event-based, and unlike DOM, it's not necessary to create any
sort of data structure which can slow things down.  You can also
read a stream into SAX (I don't know if you can do this with DOM) and
parse on the fly.  This way your information is never localized and events
can be issued as soon as the stream is read in.  It's totally cool!

Baq Haidri
Software Engineer
Inktomi Corp

At 01:54 PM 5/18/00 +0100, you wrote:
>It would be useful to have an entry in the build FAQ pointing out that
>RevalidatingDOMParser is broken in 1.0.4 and won't build. I realise
>that developers using the standard build mechanism aren't affected,
>but developers with IDE's get bitten.
>
>As an OT aside (and a newbie one at that!) can anybody offer me some
>advice? My project intends to use XML as the basis of an open request
>/ response protocol to allow various front-end and middle-tier
>processes to communicate with our server. Thus we'll be dealing with a
>large number of rather small XML documents in as near to real time as
>possible, so scalability doesn't matter but performance is critical.
>We have decided that DTD's are nasty, and won't be using them,
>although we may retrofit XML schemas when they stabilise.
>
>Firstly, is XML even appropriate for this kind of exchange? We like it
>because it's human-readable which will make it easy for third-party
>developers to talk to the server; this is important to our business
>model. But can we support the parse overhead?
>
>Secondly, should we use DOM or SAX? I incline towards SAX, since using
>DOM to build the rather detailed Document, only to then transcribe
>bits of it into a single problem-domain request object and throw the
>DOM tree away, seems wasteful. OTOH this probably means writing more
>code.
>
>Any comments?
>
>TIA,
>
>Will Dickson.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xerces-j-dev-help@xml.apache.org