[
Lists Home |
Date Index |
Thread Index
]
[ <tblanchard@mac.com>]
> Imagine I have a little app - it has some data that amounts to a
> smallish records with relationships I want to store in a file. Say its
> preference data or something.
>
Well, here are a few points. Plists are a lot like Python structures, so
you can probably do most of that easily with Python. Paul and some of the
others in this thread use it all the time. You could send a structure like
that as a string, eval() it, and get Python structures (or we can send
pickled data, but that is getting almost proprietary to Python, and maybe to
particular Python versions).
Fine and good, but I cannot send them over the network to a non-Python (or,
let's say, plist) aware system. OK, we have to have xml parsers, etc, why
not just have everybody use plist parsers, etc. right? Well, that might be
very nice and might work pretty well. So we could do that. On the other
hand, deeply nested plist-style structures start getting hard to read and
hard to manually nest correctly (bracket and brace counting problems and so
forth).
Also, we now need to get a standard for handling the other things that xml
handles, like unicode, external entities, id-style references, schemas/dtds,
etc. We can do that too, but now we are getting into substantial effort to
get them all standardized. Maybe it should have been done instead of xml
(you might argue), but it wasn't.
Second point - plists would be miserable for what is called "mixed content"
in xml or sgml, but mixed content is very important to a lot of users - most
all html, for example, is mixed content. You can circumvent mixed content
by enclosing the mixed content character pieces in special "text" tags, so
you could easily come up with a plist convention or recommended usage (or
maybe you could get away without event doing that) but by now you do not
have a nice marked-up text that is easy to read, flow, and modify. Instead
you have a hard-to-read and hard-to-change structure that does not resemble
a block of text much at all.
I have used plist-like structures (in Python) as internal data structures in
quite a few programs, and I have even serialized them to files for
interchange between programs (of my own), so I know they can be very
convenient and easy to use. I am talking about lists of dictionaries,
dictionaries of lists, and hybrids of the two. But I would dislike, for
example, converting an (x)html file to plist-style, then extracting some
data and transforming to a very different html file. I would rather do that
with xslt if at all possible.
> If I opt to use XML for the file format - that sorts of tools can I get
> for emitting the xml? I'm quite aware of parsers (you might note that
> I did the ObjectiveC wrapper for expat that many Mac programmers use).
> What is the usual emitter strategy? Is it custom code all the time?
> Are there libraries that bridge the gap? (point me to java stuff if you
> like)
Some custom code, sometimes people build a DOM structure and serialize it to
xml with standard DOM methods, sometimes people generate a stream of SAX
events and feed them to an output writer - more standard library stuff.
Wrapping it up, I would say that if your main interest is in interchanging
programming objects, xml is probably not a wonderful choice. If you want to
do RPC, it is better but still not wonderful. If you want to exchange a
wide range of data, especially hierarchically structured data with arbitrary
nesting of arbitrary substructures, it has a lot of benefits (and so do
plists, as you say), and if you need mixed content, it is hard to beat.
Plus, you can incorporate other structures (entities) by reference to their
URIs, which is not the case for plists and most other possible competitors.
And, yes, updates and deletes are still weaker than read and create
operations. And yes, relational is still better for table joins (although
in some cases xslt can do a fine job of joining structures).
Cheers,
Tom P
|
