|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: basic xml philosophy question(s)
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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








