Lists Home |
Date Index |
On Wed, 04 Dec 2002 13:11:03 -0500, Jonathan Robie <jonathan.robie@datadirect-
> But all data has a lexical representation, whether or not it also has a data
> type. I still do not understand why the presence of a data type makes it
> harder to take advantage of the lexical representation. I know that a lot
> of people on this list believe that it does - and vehemently believe that
> it does.
Think of the "HTML" produced by MS Word, and (at least from reports here)
the XML that the next version of Word will produce when one does
a Save as XML (one tag per word, perhaps, probably lots of attributes with
numeric values that make no sense without detailed documentation).
Of course, one *could* just use the lexical representation, write DOM or
XSLT code to put it into a more usable form, blah blah blah. But on the
other hand, how many
people are going to do this? It is essentially a serialization of the Word
model, using a complex and very strongly typed schema, and the path of
least resistance by far is to use Word to edit the stuff.
(Which, ahem, is probably the whole point).
More generally, the more you rely on the "data types"
(very broadly defined) to define and process the XML, the less useful it
will be for
anyone who doesn't use the same semantics, type sytstems, language
etc. as you do. This is not *necessarily* a Bad Thing, it just produces a
tighter coupling between producers and consumers of the XML than the
"bohemian" style that Uche discusses. Tight coupling has its advantages,
it lets you do all that compile-time static typechecking stuff. The point
it also has its disadvantages: fragility across time, non-portability
(e.g. with different conceptions of dates and integers), dependence on a
vendor, etc...... all those things that XML was supposed to take us away