DOM or SAX2 xml handling?

[bhs-ittech]

I'm currious about which XML parser is used most.

I my self have found the SAX2 easiest to use.

But how about you? Which do you use and why?

[Kumosan]

This question does not make any sense. There are problems, which are easier solved with SAX2, others with DOM. DOM and SAX2 are tools, good developers know both and know when to choose which.

[Brandybuck]

You use the different parsers depending on your needs. DOM parses the XML and creates a complete tree for you. It's easy to use, but takes up a lot of memory. SAX parses the XML token by token and calls the handlers you've written to deal with them. It's more work up front to use, but doesn't consume much memory.

[camel]

What about Option Number 3?
QXmlStreamReader and QXmlStreamWriter

[wysota]

AFAIK it is to make SAX obsolete - the idea is simmilar, it's just easier to handle. Personally I use DOM. I think I might do differently for handling really large xml files, but as I don't have to deal with such files, I don't have to deal will a sequential approach.

[Kumosan]

I think I might do differently for handling really large xml files, but as I don't have to deal with such files, I don't have to deal will a sequential approach.

SAX2 is not necessarily about large files. For instance it can be easily utilized to create print layouts. You have your handles, which draw circles, lines, text, etc and the SAX parser calls them sequentially with parameters from the controlling XML file. This way you 'draw' to a QPrinter.

In this scenario you are not interested a particular data structure in memory. Choosing DOM would be definitely the wrong tool.

I don't really see SAX2 and DOM as interchangeably. When your problem actually demands a DOM approach, but because of memory problems you are forced to use SAX2, it always is an ugly crutch.

I'd say: Use SAX2 if you have to control something, use DOM if you have to store something. Of course this is only a rough guideline.

[wysota]

I'd say: Use SAX2 if you have to control something, use DOM if you have to store something. Of course this is only a rough guideline.

If the xml stores a sequence then I agree that using SAX is easy with it, but I wouldn't say you shouldn't use DOM. Depends how you want to handle the data - if it has some kind of hierarchy which you want to process in a non-sequence manner, it's easier to use DOM.

And the obvious benefit of using DOM is that you don't have to implement any handlers

[bhs-ittech]

If the xml stores a sequence then I agree that using SAX is easy with it, but I wouldn't say you shouldn't use DOM. Depends how you want to handle the data - if it has some kind of hierarchy which you want to process in a non-sequence manner, it's easier to use DOM.

And the obvious benefit of using DOM is that you don't have to implement any handlers

Exactly the lack of handlers in DOM made it difficult for me to understand.
And its tree structure thingy.
I can only atm see one application for that; for parsing configuration files which
are somewhat static in layout.
(I still haven't figured out how to use DOM though)

the SAX on the other hand made just enough sense that it was easy to implement as
a handler to server generated responses.
Where some tags meight popup and meight never, and where the general structure
could change from call to call.

thanks for all the feedback and oppinions,

(and on a side note could all please disregard the word offcause in the selection choises )

[PaladinOfKaos]

The only app I've written that uses XML used DOM, mostly because I hate writing handlers. DOM is actually pretty useful for anything with a tree structure. You can easily pass subtrees around to different functions. For example, with this XML fragment:

<scene>
  <models>
    <model/>
    <model/>
  </models>
  <textures>
    <texture/>
    <texture/>
  </textures>
</scene>

<scene>
  <models>
    <model/>
    <model/>
  </models>
  <textures>
    <texture/>
    <texture/>
  </textures>
</scene>

To copy to clipboard, switch view to plain text mode 

DOM is great. You have a readTextureInfo() function, and you can pass it the node corresponding to the <textures> element. It can then handle the textures as it sees fit. (I'm actually using this style in an app I wrote I while back, though it's not Qt based.)

I would probably use SAX for a configuration file, or something else that's kind of flat-ish.

[yogeshm02]

I'm using DOM where hierarchy is known and SAX2 otherwise i.e. most of time i'm using SAX2