xml-dev - Re: basic xml philosophy question(s)

["Laurent Bossavit" <morendil@micronet.fr>]

rsanford sez:

> do most of you use event-based (sax, expat, etc) or dom parsers?
> why? 

That mostly depends on the situation and the application. Event-based 
parsers are neat when you're stingy with CPU/RAM, when you need to 
process the data in real-time before the parse is fully finished, or 
generally when whatever you do with your XML doesn't involve creating 
a full in-memory tree representation that can be manipulated after 
parsing - you'd use DOM for that rather than reinvent the wheel.

Examples of applications well suited to SAX would include 'immediate' 
processes such as chat/messaging or request/response mechanisms. SAX 
is also nice for lightweight object (de)serialization, see Bill 
LaForge's MDSAX/Quick (http://www.jxml.com/). Probably a lot more 
besides...

DOM is a good bet if you need to parse a document, modify it in some 
way, and save it back or send it on elsewhere; or if you know little 
of the structure of your data in advance, or, again, probably in lots 
of other situations.

> do any of you use any additional parsing libraries to
> make your lives easier? which ones? why or why not?

XPath makes your life a lot easier generally. XPath was initially 
associated with XSLT but is emerging as an entry-level query language 
for task such as locating data of interest, grep-type matching, or 
event event dispatching (see XMLBlaster). XPath rocks.

> is it better to use element-based xml documents where an
> element's "attributes" are expressed by sub-elements such

Same kind of answer : it depends... Neither is "better" in the 
absolute unless you're an advocate of SML; they want to do away with 
one of them entirely - you only get one guess which.

Elements can be used where ordering matters, or might matter; if you 
use attributes, you're saying ordering will never matter; no parsing 
API makes any guarantee as to order of attributes. The content model 
of an element can readily be extended to contain other elements; that 
is of course not the case for attributes. IOW, attributes will always 
hold string values while elements, generally, may hold complex 
values. If you're using SAX, using attributes for data that you will 
want to read "first" makes sense, with element data possibly deferred 
for later. Attribute names are unique within an element, while an 
element may contain multiple elements with the same name. Overuse of 
attributes leads to the problem of "microparsing" as in SVG, overuse 
of elements leads to text bloat, and SML.

All of these distinctions add up to "expressive power" - deciding on 
using an attribute or an element for a given bit of data is a way of 
indicating what such data is *for*.

Tim Bray remarked that XML was "just small enough". I think the 
element/attribute duality is a good example of that.


-[Morendil]-
How come wrong numbers are never busy?


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************