[
Lists Home |
Date Index |
Thread Index
]
Patrick Durusau wrote:
>> XML's lack of a data model is a deliberate, careful design decision,
>> and the evidence of recent years is that it was correct.
>
> I obviously disagree but was wondering if there is a record of this
> "deliberate, careful design decision" in canonical or non-canonical
> documentation about the drafting of XML? (If enforced nesting of
> elements is not a defacto data model I am not sure what definition is
> being used for data model. Not using the words "data model" does not
> make it any less a data model.)
Well, the syntax of XML certainly puts constraints on what kinds of data
models you can reasonably use for it; but we've already seen a
remarkable variety of approaches, even in small subsets of the universe
like Java XML APIs.
As for the decision, it was all over in about 45 seconds on one
teleconference, I remember it clearly. Fairly early on in the XML
design process. Someone (maybe me? I forget) said "er, should we do an
API as well?" and James Clark said "isn't the idea that there's going
to be one API that's going to work for all the different things you want
to do kind of silly?" and everyone said "oh, right" and that was that.
Below is a rant I wrote on this subject to a mailing list some years ago
and have regularly re-posted. -Tim
=====================
It took me years to realise how deep and important the divide is between
wanting an SDK and wanting to know the underlying protocol. Too much of
our biz can only see one of these realities. I grew up with networked
minicomputers and (mostly) Unix, and maybe that's why, in the final
analysis, I always want to see the bits on the wire, because in the final
analysis, given any programmable device, I can work with them.
XML is of course the ultimate expression of that philosophy; it can
do a reasonably good job of offering a bits-on-the-wire view of just
about anything.
During the heydey of client-server I was repeatedly baffled and frustrated
by the mind-set, in particular evidence chez Apple and Microsoft, that the
only expression of computing reality was a big hairy complicated API with
an associated big hairy complicated (and often expensive) SDK. This is not
just a Unix-vs-PC thing - the X window system is one of the most extreme
examples of the big, hairy, complicated, API (the rumor that they ever
actually fully documented the wire protocol is false).
And not that this approach is wrong - I'm sitting in front of Windows
box, and three of the windows are X applications running on my
big server which off at a distant ISP.
These days I write big complicated software in Java, which does a good
job of giving you a tractable object model overlaying insanely complex
infrastructure. But in a distributed int{ra,er}-net scale app with
heterogeneous boxes, there's still no substitute for the bits on the wire.
Our profession needs to grow up a bit and actually arrive at a
consensus as to when each of these approaches is appropriate, teach it
in college, and so on. -Tim
|
