[
Lists Home |
Date Index |
Thread Index
]
On Thursday 24 October 2002 21:27, Paul Prescod wrote:
> 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, ...)>
That agrees nothing!
Do you deny that groups of people get together to produce things like XHTML,
and vertical industry message formats? Because they do. The presence of DTDs
and schemas doesn't remove this requirement. You've used XML; you've probably
noticed that the DTDs and schemas you use have comments on them saying that
somebody wrote them once, they didn't just magically come into being as soon
as two people had applications that might interoperate.
Well, it's just the same with TSV, SQL databases, X.500, LDAP, raw binary
files, and so on. If you take the time to study the history of the problem
you are stating that XML can solve, you will notice that the presence of a
standard formal schema language for a given interchange system makes
relatively little difference. It can be handy to be able to validate stuff
from time to time, but it's no ground breaker. If you provide an invalid PNG
file the program reading the PNG will complain, just as if you provide an
invalid XML document to some XSLT it will barf as soon as it tries to find an
element that's not there.
> This is both human readable and computer processable. There are a
> variety of similar techniques. Now what's the equivalent for TSV,
> PLists, etc.?
Some have formal schema notations, some just use English :-)
The Internet protocols don't have a formal schema notation, they're just
defined in English in RFCs. And they're more widespread than XML, I reckon;
it hasn't harmed them, has it?
> > 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.
Stop and think about that. What differentiates these products, hmm? Do I buy
Corel because it uses a different in-memory data structure to xfig? If a
package uses a really bad data structure and is slow or buggy because of it
that might come into my purchasing criterion, but the developers shouldn't be
worrying about the data structure unless it's actually *broken*...
> > 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.
Yep, just because I know more about bitmap file formats - overall, we are
discussing data interchange in general; you brought up vector files as an
example, I bring up bitmap files.
> > 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.
Read what I said before flying off the spout with something irrelevant :-)
"...into memory as a character array..."
Not a *byte* array!
> > 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.
No I'm not, read what I said.
> 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.
So be amazed! Because that's precisely what happened. We provided CSV, TSV,
and XML inputs, and the XML one got dropped after a few versions since the
only time it ever got used was when we demonstrated it.
We'd go to the tecchies of the company we were setting up the interchange
with and say "We can accept bog standard CSV or TSV with the following column
headings, or XML with this schema. What do you want to make?" and they'd say
"Um... we'll send a CSV, thanks". We didn't even bother offering to send
people XML, they always wanted something they could just import directly into
applications, and CSV is wider supported than XML - it's been around a lot
longer.
> I'll ask again: what's the schema language for plists?
See previous answer...
> Paul Prescod
ABS
--
A city is like a large, complex, rabbit
- ARP
|
