[
Lists Home |
Date Index |
Thread Index
]
On Thursday, October 24, 2002, at 07:48 PM, Paul Prescod wrote:
>> 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.
We will have to agree to disagree. It has the same level of
brittleness and exposes the underlying structure the same way.
>>> 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".
Fine - lets leave objects out of it and say tuples and relationships -
OK? Thats pretty much what SQL gets you and I can easily map that to
objects or lists and back. Which I can't say about XML. Its
inconvenient that way.
> 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.
Hmmmm. If the process is strictly a consumer - I'll agree that this
might be desirable. If its a peer participant (IOW it updates and
returns modified version of same data) - no way.
...
>> 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?
Yeah, but the XML representation is so fugly that nobody that writes
one by hand uses the XML format. Also, I think you'd cringe yourself
at what is represented - nothing semantically interesting. You get
something like (off the top of my head)
<dictionary><key>CDs</key>
<array>
<item><dictionary>
<key>artist</key><string>Alice Cooper</string>
<key>title</key><string>Goes To Hell</string></dictionary>
</item>
</array>
</dictionary>
vs
{ CDs = (
{ artist = "Alice Cooper"; title = "Goes To Hell"; }
);
}
Which one takes you longer to identify the data and visualize the
structure? The api lets you write either format - I always use the
classic version (and most of apple's internal tools do too).
> That's the problem. How can I know _what combination_ of map, list and
> string to expect as the output of any paritcular program?
Read the documentation? Look at an example? Thats now it generally
works. FWIW, as far as I can tell, this is how it works in the XML
world too. Nobody I know sits down to write and XML schema or DTD.
They write a sample document and use a tool like XMLSpy to generate the
definition from the example.
>>
>> 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.
Actually, PLists are often used as the internal model. You just slap
objects around the structure and use the PList collection as the
internal store. BTW, the key value coding pathing works on regular
objects as well as PList collections - its exactly the same. So you
can substitute regular objects in the PList and they serialize out fine.
I have done the same thing with Java and reflection. Works fine.
> 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?
Write a document describing it and maybe a program that uses the
documented format. Same as with any other file format. This is how
the address book schema is getting extended.
> Dude: today, plists are XML. ;)
Not quite. I've written stuff to build PList memory structures from
XML documents. The turn out to be a bad fit for practical use.
Attributes end up being treated weirdly and while reading, you can't
quite tell if the tag you just read is going to end up being a value, a
dictionary, or a list, until you've read several other tags.
Bottom line, the results were unsatisfactory and I abandoned the
approach because I didn't end up with convenient data structures.
> 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?"
I'll toss my suspicion in - ignorance. Apart from PLists - I haven't
seen a text editor modifiable structured data serialization format
provided as a basic utility in a development environment published.
This capability is new to most of the world.
> If you want to understand, first invent vector graphics
> and purchase order models for plists (old-style or new, doesn't
> matter).
Been done.
> Then write a schema (how?) for them so that you can communicate your
> wire representations to other programmers.
You just describe the format in a document. Its very easy. The parser
makes it trivial to read the thing into memory in a very convenient to
use format. I can't say the same for the XML parser solutions we have.
I can write custom code (SAX) for every freakin schema out there or I
can use the DOM (a weird shaped gizmo). Neither is too practical.
|
