[
Lists Home |
Date Index |
Thread Index
]
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.
> 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.
>
> 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 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.
>> ... There's nothing wrong with that. I'll go so far as to say that
>> a universal object interchange format is a good thing. A way to
>> serialize object networks that is useful for data interchange is a
>> good thing.
>
> You are presuming that people want to interchange objects. But they
> don't always (or even usually) want to interchange objects. They want
> to interchange data. Some nodes will represent the data as objects.
> Some nodes will represent it as lists of list. Some nodes will
> represent it as hashtables. That's loose binding.
Some nodes have weird extra information like attributes that don't map
to anything in an ER model. People want to interchange information.
Data without structure and context isn't terribly interesting.
>> But XML doesn't look anything like what you would get if you were to
>> serialize a network of objects. Its quite different. Worse, the
>> object to XML serialization scheme is open to interpretation in a big
>> way. (I know attributes vs elements is an oldie - and I don't want
>> to respark debate). The mapping between XML and say ER models isn't
>> very clean or well defined.
>
> Right again. That's the beauty of it!
The beauty of it is its inconvenience? I don't get it.
> If you consider impedance mismatches a problem, then yes, XML causes a
> huge problem.
I do and it does.
> 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.
> Now I know the origin of those horifically silly, dumbed-down data
> structures on my Macintosh harddrive.
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 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.
> What are the schema, addressing and transformation languages for
> plists?
Schema? There's only 3 things, Map, List, and String.
dictionary: { key1 = value1; key2 = value2; }
list: ( item1, item 2 )
string: token | "String with spaces, {}'s and ()'s need quotes but
tokens don't"
Mix them in any combination you like. Addressing is via key-value
coding. Here's a brief example:
{
CDs = (
{ artist = "Alice Cooper"; title = "Goes to Hell"; },
{artist = Aerosmith; title = Pump; }
);
Movies = (
{ title = "Toy Story"; studio = Pixar; },
{ title = Casablanca; studio = "Warner Bros."; }
);
}
// get it from disk
id plist = [[NSString stringWithContentsOfFile: @"filename.plist"]
propertyList];
// get a list of CD titles
id titles = [plist valueForKeyPath: @"CDs.title"];
// change it - add a movie
[plist takeValue: [NSDictionary dictionaryWithObjectsAndKeys:
@"title",@"Monsters Inc", @"studio", @"Pixar",nil] forKeyPath:
@"Movies"];
// save it
[plist writeToFile: @"filename.plist" atomically: YES];
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. Maybe you can
enlighten me there. But as far as I can tell, all new XML is custom
emitted from code.
There is no transformation language for Plists - its too easy just to
write code. A transformation language would be trivial to create if
one were desired though.
> Also, consider that plists are typically not shared between many
> different programs.
Yes they are. The locale database (timezones, month names, etc) on
your Macintosh is all stored in Plist format and used by core
libraries. Same with the Mac address book. Actually, since the format
is so flexible, it lets developers add extra info to the Mac address
book from their programs thus making the thing a shared customizable
datastore.
The entire defaults system is based on this mechanism - all user prefs
are stored this way.
Plus, I like the PList syntax - I can read it without getting
eyestrain. I can't say the same for the overly verbose markup syntaxes.
> Is there any plist-vocabulary that has _hundreds of tools_ around it
> like XHTML, RSS, SVG or Docbook?
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.
> The more vocabularies are shared, the harder it becomes to extend or
> modify them without breaking any particular application.
That hasn't been the case with PLists at all. They're easy to extend.
You can add extra entries without breaking things. Removing things or
moving things relative to their keypath is not recommended.
> 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?
> Because plists are typically not shared, there is no need for a schema
> language for them and seldom an impedence mismatch between them and
> their applications. Which is to say, they are not in the same problem
> space as XML.
And yet, I manage to use PLists to do the job faster and more easily
every time one of my peers (who is very fashion conscious) reaches for
XML.
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.
Todd Blanchard
|
