[
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.
node.appendChildNode("foo")
doc.toXML()
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
implementation.
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
|
