Re: [xml] "Proper" way to use XML (not library specific)



Thanks guys for your thoughts.  (Rush, I did reply to your last
communication with me re: library selection, but it bounced on your
address.  I think I tried resending, not sure.)

To address some of the questions raised about how the Profile will be
used, the use case here is quite simple.  The profile is read-only,
there will never be a reason for the application to modify its own
configuration.  The application opens the profile once at
initialization, reads its config parameters, which may be a small subset
of the total depending on how many applications it contains, and
discards the profile.  The queries themselves are quite simple, just
"gimme the value that matches this application/section/item ID".  

It seems to me that either way, the contents of the file must be loaded
into a memory structure, either a DOM or one of my own creation, and
then a means must be provided for randomly accessing specific pieces of
the data.  Going DOM/XPath, that is all provided by the API.  Going the
marshalling route, I have to build all that myself, and the additional
flexibility/capabilities this method provides aren't needed here.  Given
the simplicity of what we are doing, marshalling seems to be unnecessary
work.  If I did do it, I would certainly use the SAX interface.  No need
to load the data into one structure just to reload it into another.

Thanks again, you've given me some things to consider.

-will

-----Original Message-----
From: Rush Manbert [mailto:rush manbert com] 
Sent: Wednesday, February 14, 2007 2:08 PM
To: John Dennis
Cc: Will Sappington; xml gnome org
Subject: Re: [xml] "Proper" way to use XML (not library specific)

John Dennis wrote:
On Wed, 2007-02-14 at 11:58 -0500, Will Sappington wrote:
be designed to do specifically that with XML data.  So why would it
not be an appropriate tool to use for migrating our existing
name/value pairs (.ini files) to XML?


Bottom line, you can do it either way. Irrespective of whether you
marshal the data into your own data structure or reference it directly
in the DOM tree you still will as a first step need to locate the data
in the XML file, XPath is a very convenient way to do this. But it
does
require you know what to query a priori, a lot of times that's not the
case (see comment about SAX below)

As to whether the queries in your API reference the DOM directly via
XPath, or a private data structure you built from the DOM is an
implementation choice dictated by your particular circumstances.

However, do consider the option of using SAX, not DOM for your
purpose.
SAX is well suited to marshaling config file entries. The idea is your
SAX callbacks build the marshaled data structure as the file is
parsed.
There is a tremendous advantage to this because the marshaled data
"builds itself".

It's not unusual to discover a marshaled data structure is easier to
work with once built, especially if any of the data needs to be
normalized, validated, or cross referenced in any manner.

Hi Will,

What he said. :-)

You can expose the same top level API in either case. However, if you do

marshal the data into classes and use STL (I'm thinking maps or 
multimaps here), then you get a lot of pretty direct support from the 
STL classes. Your data is also highly mutable, if you need that sort of 
thing, and would be easy to un-marshal back to XML if you need to write 
out the config. If I needed to do that, it would tip me to use classes 
because it's not very easy to modify the DOM. (I don't know about 
streaming APIs because I haven't used them.)

As in the original library selection discussion, it might come down to 
that "today we make cigars, but next year we're going to start making 
H-bombs" thing again. But then, if you used Xpath and wrapped it in a 
class with a good API and good encapsulation, then when it's time to 
start making nuclear devices you could always change the underlying 
implementation to use classes/STL and no one would be the wiser. On the 
third hand, though, maybe you should just make your boss happy and use 
the class approach. It's a good excuse to learn to use STL if you 
haven't done it before, and it might get you a better raise come next 
review time. There are just so many factors to consider here!

- Rush



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]