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

["rsanford" <rsanford@nolimitsystems.com>]

i'm used to getting data out of a database and building up trees
of objects and the relationships between them and then playing
with that tree of objects to accomplish whatever it is that i
need to accomplish. and when i'm done with it, each object knows
how to store itself back into the database. yeah!

right now i don't need to manipulate the data that i'm receiving
as an xml document, i just need to store it. i know what the dtd
is beforehand so i know the structure. it is straightforward 
to use the dom parser to build up a tree of psuedo-objects and
query them for their properties and store that into the database.
but i do have to admit that i think the syntax for doing that is
really ugly. i understand why it is that way, but i still think
it is ugly.

so i look at sax and think that building up a FSA to create my
sql statements would be, ummmmm, an interesting exercise.

or, i can create a parser that builds up an object model that
encapsulates the dom but uses a more attractive syntax to retrieve
properties.

i think my problem may be that i'm used to being a windows coder
where microsoft doesn't let you make too many decisions of your
own and i am feeling overwhelmed by choices :)

rjsjr

> 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/
> ******************************************************************
> *********
> 

***************************************************************************
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/
***************************************************************************