[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What is XML For?
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|