OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] What is XML For?

[ Lists Home | Date Index | Thread Index ]

tblanchard@mac.com wrote:
> On Wednesday, October 23, 2002, at 09:32  PM, Paul Prescod wrote:
>> You keep talking about queries
> This thread started with the suggestion that replacing embedded SQL in a 
> web page with XML requests was somehow superior.  I maintain that its 
> not.  Its just different.

I've demonstrated that it is superior several times. Every time I do, 
you up the ante and bring in objects, as if SQL and objects are the same 
thing. I thought it was pretty commonly understood that putting SQL in a 
web page is a terrible idea for a variety of reasons, not least security.

>> Here's the canonical (silly) example:
> Sorry, I absolutely refuse to take seriously anyone who ever brings up a 
> stock quoting service as an example of distributed computing.  Its 
> trivial, stupid, and a cliche besides.

It was a simple example that got across the point. I get the feeling you 
aren't interested in communicating here.

>> The XML document is a _representation_ of the underlying data. It 
>> could be (and usually is) generated by a Turing complete process. You 
>> know nothing about the underlying data except what the process chooses 
>> to show you.
> Yeah, so?  The database schema isn't particularly related to the storage 
> of the bits on the disk drive either.  Its just the old perspective 
> argument: "your model's view is my view's model".

You are incorrect. The database engine chooses a representation on disk 
that will allow it to quickly fulfill the requests it expects based upon 
the schema. I'm sure that a foreign key has a very different bit 
representation than an ordinary column.

>> You need an output for a transformation. An XML document is a very 
>> convenient output. A SQL view is a very inconvenient output. You asked 
>> about the difference between SQL and XML and there's your answer.
> Convenience is in the eye of the consumer.  I find XML a very 
> inconvenient format relative to objects.

Here goes the old "switcheroo". First we're talking about XML versus 
SQL, then XML versus objects. You asked about SQL versus XML. I've 
answered your question several times. Then you bring in objects, which 
is a totally different argument. Then you bring in plists (which are 
_not_ objects) which is yet another argument.

>> If you consider them an opportunity to use the best techniques for a 
>> particular job, then XML makes more sense. Relational databases are 
>> kick-ass for holding a kind of information. Objects are wonderful for 
>> in-memory representation of that information. Objects and relations 
>> have an impedance mismatch because they are solving different 
>> problems. XML and objects have an impedance mismatch because they are 
>> solving different problems.
> Which problems are those again?  Because I'm still not seeing the 
> driver.  Maybe I'm lucky and don't have those problems but so far XML 
> doesn't look like anything I'd invent on my own.

XML allows the interchange of information between processes that will 
bind their _own_ behaviour to the information because only they know 
what behaviour they need.

> I wouldn't look down my nose at PLists.  I find them superior to XML in 
> every way.  Not the least of which, XML is (as far as I can see) a read 
> only (transient if you will) format.  PLists are read-write (persistable).

I have no idea what you are talking about. If plists are (today) 
represented in XML and plists are read/write then how can XML be read-only?

>> (I got quite a kick out of them) Anyhow, plists are so 1990s.
> OK, now you deserve insulting. But I won't. Suffice it to say this last 
> statement makes  you much less convincing than anything you've said so 
> far. I'm told I've always been fashion impaired. I just use what works.

It was a joke, son. Laugh!

>> What are the schema, addressing and transformation languages for plists?
> Schema?  There's only 3 things, Map, List, and String.

That's the problem. How can I know _what combination_ of map, list and 
string to expect as the output of any paritcular program?

> That last bit - manipulate the data and then write a modified version of 
> it is something I don't see an analog for in XML. 


Of course, this only works when you use the DOM as your internal model, 
and that only makes sense in the same sort of circumstances where it 
makes sense to use plists as your internal model. More often, your 
internal model is entirely divorced from the file representation.

> 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?

> I just gave you one.  More are arising all the time.  Also, I've never 
> used all those tools you're talking about - the the PList format is the 
> basis for probably 80% of the file formats of those Mac programs you use.

Dude: today, plists are XML. ;)


>> Which is to say that in the types of applications XML is designed for, 
>> there is _almost always_ an impedance mismatch between the _shared 
>> representation_ of the data and the _in-memory_ representation that 
>> any particular application uses.
> And these applications are....what?  If we're designing an exchange 
> format, why must it have such a huge mismatch between how most data is 
> modeled and how it is exchanged?

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?

It is impossible to align the internal model with the external 
representation AND allow competing internal models. I personally am not 
willing to allow my internal model to be dicated by the wire 
representation: that would be a classic confusion between interface and 

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.
> The rest of your argument comes down to "if you're right how come nobody 
> else agrees with you".  That argument wasn't that convincing when used 
> against Copernicus.  Its not convincing now.

No, the question is not: "why does everyone disagree with you." The 
question is: "Why didn't the techniques you describe meet people's needs?"

If you want to understand, first invent vector graphics and purchase 
order models for plists (old-style or new, doesn't matter). Then write a 
schema (how?) for them so that you can communicate your wire 
representations to other programmers.

Then write processors for your plist formats in an object oriented 
language, a procedural language and a functional one. By the end, you 
should understand how XML is not like SQL, XML is not like objects and 
XML is not like plists.

Unfortunately, I'm out of time for this discussion.

  Paul Prescod


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS