Lists Home |
Date Index |
- From: Tagore Smith <email@example.com>
- To: "W. Eliot Kimber" <firstname.lastname@example.org>
- Date: Fri, 11 Feb 2000 00:56:17 -0500 (EST)
> But, if I want to *address* a particular token, the token nodes are
> there and I can address them reliably.
> In a DOM context you'd probably say "but nobody will ever need to do
> that". Probably right, so in the *implementation*, don't bother to
> expose that complexity. But a standard data model like the SGML property
> set can't presume to know the full requirements of potential users, so
> it has to be more complete (and therefore complex) than a purely
> pragmatic specification would need or want to be.
If you want to really be able to "write once, present anywhere" this
seems like a basic requirement. It seems to me that an addressing scheme
_has_ to be able to address down to an (arbitrary) atomic level. It seems
to me that not having a unified model for addressing is likely to result
in significant costs.
> It's important to remember that XML simplified SGML *syntax*. It did not
> (and could not) simplify the underlying abstract data model (except
> where the SGML data model reflects optional features, like attributes
> for notations).
> This is why the idea that XML is *fundamentally* simpler that SGML is a
> Big Lie. The cost of entry is lower, but the total cost of ownership is
> essentially the same.
There seems to be a rift developing in the xml world between those who
want to use xml as a better EDI and those who want to use it as part of a
system that presents documents to humans. In the first case xml seems a
lot more appropriate, and a lot cheaper than sgml. It's probably a bit
better than csv files too. In the second, its main advantage over sgml
seems to be that it has a lot of momentum behind it. If I say to a client
"I think we should go with an xml based system here" I can be pretty sure
(after Microsoft's last foray into advertising) that they won't give me
the same look they would give me if I mentioned SGML.
As to the simplicity of xml- with all of the ancillary specs I'm not
entirely convinced. If you threw them _all_ into the front row of an
audience- well you'd need a good lawyer, because you might kill someone.
In the end, I agree with Mr. Kimber on this (we're coming from opposite
ends of the spectrum here- he holds his opinion with a great deal of
knowledge, while I hold mine in a condition of some ignorance): the
complexity of the data model is in the end what matters- maybe not for the
lightweight apps, but certainly for the heavyweights. Gorves and
architectural forms at least seem to offer some compensation for the
At any rate, I've written enough (maybe too much). I'm a novice in this
field (although I'm _really_ familiar with the process that old media
companies go through trying to become new media companies) and although a
lot of what I said above was phrased declaratively, I mean it more as a
series of questions than a series of statements.
One more thing: for those following Quark's products, is it my
imagination or have they pretty much completely missed the point?