[GD-General] (Really) XML for portable preferences library

[Jeff <je...@sp...>]

Me:
>> I'm surprised that no-one has said "use XML format please" - its
>> not that painful, given that you'll have a fairly limited schema
>> to implement.

Brian:
> So here's a question -- I know that whenever a discussion about text
> file formats comes up there is often a "use XML" grenade tossed into
> it.

And didn't it raise a firestorm this time, with an inordinate number of
people who didn't seem to be able to understand that a file format for a
PREFERENCES system need not have the same requirements as those for a 3D
LEVEL loader...

Brian:
>  Now, I can think of a lot of reasons NOT to use XML (i.e. it's
> overkill, for one), but I'm curious what real, tangible reasons for
> using XML exist, as opposed to a simple application specific structure
> (like INI files).

Me: (answering Brian's question)

A little has been said about the viewability of preference files in apps
like IE, and this is certainly an advantage.

XML also has standard(?) rules about encoding that let you deal with how
you'll store <> characters - your .INI needs similar rules for escape
characters (or quotes, or whatever...)

What I haven't seen in any of the discussion is anyone pointing out that XML
handles STRUCTURE very nicely.  At this point, your preferences library lets
the user write out integers and strings - however, its fairly
straight-forward to write out OBJECTS (or structs if you prefer).

Inhouse we use expat and have a simple shim wrapped around it that knows how
to write our favorite data structures, the most complex of which is a list
which contain lists (ad infinitum) which can contain ints, reals, strings,
points, lines, etc.  XML handles the nesting very nicely - if we used .INI
files we'd need to reinvent XML (or use some hideous key-naming scheme that
appended digits every time we went down a level)

Whilst you mightn't advocate points and lines for most peoples preferences,
think "saved window positions".  You might do:

<WINDOW name="toolpalette">
    <POS X=123 Y=456 />
    <SIZE H=100 W=200 />
</WINDOW>

As a bonus, if you use a more specific tag than POS, say WINDOWPOS, then
your XML loader (as opposed to your application) can even be smart enough to
clip its values based on the current screen size.  It means that you've
encoded more intelligence into the basic data types that you are storing,
this is true, but then you don't need to use them if you don't want to.

My main objection to XML, or perhaps its just expat's parser, is the
processing of whitespace. Expat calls you back each time it processes a
LINE, which means that any data types that get split over a line (perhaps by
someone's favorite XML editor) mean you need to implement your own buffering
to tie things back together.

Since the four lines of my email signature are a preference, its important
to me that any preference system handle multi-line strings correctly.

And finally, 

<MARKETTING>
If you use XML, you get to say "... and it uses industry-standard XML files"
and you get to watch the industry beat a path to your door because your
product is *obviously superior*.
</MARKETTING>

;-)

Jeff Laing <je...@sp...>
-------------------------------------------------------------------------------
"Meetings.  Don't we love meetings?  Every day.  Twice a day.  We talk." He got
on one elbow.  "I bet if I blew the conch this minute, they'd come running.
Then we'd be, you know, very solemn, and someone would say we ought to build a
jet, or a submarine or a TV set."       -- William Golding, "Lord of the Flies"