[
Lists Home |
Date Index |
Thread Index
]
Alaric B. Snell wrote:
> On Thursday 24 October 2002 18:48, Paul Prescod wrote:
>
>
>>>Yes they are. The locale database (timezones, month names, etc) on your
>>>Macintosh is all stored in Plist format and used by core libraries.
>>
>>All of these libraries are under a single point of administrative
>>control. How do I define a purchase order schema for PLists that will be
>>used by thousands of independent processes?
>
>
> The same way you'd do it with XML, or TSV, or anything! XML doesn't make
> interchange any easier. You still need to agree what XML structure to use, or
> what column headings to use, or whatever.
Really? Here's (one way) I would do it in XML:
<!ELEMENT purchaseOrder (buyer, seller, ...)>
This is both human readable and computer processable. There are a
variety of similar techniques. Now what's the equivalent for TSV,
PLists, etc.?
>...
>>Do you think that SAP and Quicken use the same object model for a
>>purchase order _internally_? Do you think that Word and Wordperfect have
>>the same internal model of a document? Do you think that CorelDraw and
>>Adobe FreeHand have the same internal model of a vector graphic?
>
> Yes, I think so. The only differences between them are incidental, and if
> they all used the same file format for interchange then the only differences
> would be names of fields. And if this file format was nice enough to have
> automatic mapping into software objects, not even that!
I don't know where to go from here. It is unfathomable to me that the
people at Corel would give up the opportunity to define in-memory data
structures optimized for the algorithms that differentiate them from
their competitors. Same for SAP, Quicken, Word, WordPerfect, etc.
>...
>>Therefore I accept that when I write a vector graphics program, there
>>_will_ be an impedence mismatch between the file formats I must deal
>>with (under the control of standards bodies rather) and my internal
>>representation (under my control). Such is life.
>
>
> Not really! Quite a few 'standard' bitmap file formats are just dumps of the
> memory structures used by the apps that first produced them - and they're all
> roughly the same: header, palette, bitmap data.
I'm talking about vector graphics programs. You're talking about bitmap
apps.
>...
> Sometimes you add extra pointers and indexing information when you load
> something, when loading a text file it's quite common to slurp it into memory
> as a character array but keep an array of indices of the starts of lines for
> fast movement to a given character position. In almost all plain text
> processing the in-memory and on-disk representations are *identical* with a
> few extra pointers put in, maybe splitting lines out into a linked list at
> worst.
Not in my experience. The text editor I worked on allowed Latin1 and
even EBCDIC input but would never, ever use those encodings internally.
>...
> I wouldn't say everyone disagrees with not using XML for stuff, it totalled
> failed to take off in many industries I've seen. CSV still rules the wires
> when it comes to exchanging databases, I'm afraid. We discontinued the option
> of providing XML to our database because nobody used it.
"Providing XML to our database." I don't think you've been hearing what
I've been saying about the kinds of applications XML is strong for. You
are talking about dumping your internal model as XML. That's a marginal
use of XML. If you and your competitors and partners need to get
together and define a standard interchange format for structured,
linked, perhaps-hierarchical data, I would be amazed if you found CSVs
more convenient.
>...
> They clearly do! The plists have been in use on macs for how long, Mr.
> Blanchard? :-)
And today they are XML. ;)
> XML for data interchange has not filled a gaping need. An increased desire to
> exchange data online came around, and XML was a hot new thing happening in
> the W3C - aimed at replacing HTML on the Web at the time. So the people who
> wanted to interchange data used XML. They would have done just as well had
> XSLT and so on been developed on top of plists rather than XML, and maybe
> better - plists have a richer basic data model, it's a tree with seperate
> notions of key:value mappings and sequences rather than rolling both into one
> (with the old problems of what to put in attributes and what to put in child
> elements and mixed content and so on).
I'll ask again: what's the schema language for plists?
Paul Prescod
|
