[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 04 December 2002 18:56, Mike Champion wrote:
> On Wed, 04 Dec 2002 13:11:03 -0500, Jonathan Robie
> <jonathan.robie@datadirect-
>
> technologies.com> wrote:
> > 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
> object
> 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).
The debate is about strongly typed stuff being bad, right? This looks like
you're saying "This thing that horribly abuses XML also happens to be
strongly typed so strong typing is bad", then? :-/
> 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
> bindings,
> etc. as you do.
I don't think so. Adding more restrictive typing doesn't change the data in
the documents, it just makes automated processing easier. Instead of allowing
a date field to contain "yesterday", "my birthday", "1/2/2002" (note the
ambiguity; 1st feb or 2nd jan) and so on you restrict it to a specific date
type written "YYYY-MM-DD", and the increased rigidity makes it possible to
write code that can be shown to handle all the cases.
Is that the problem? Does it bug you folks that you are restricting the data
you are allowed to transfer in a given vocabulary to what programs can be
statically declared to deal with? Requiring later versions of the spec (which
defines both the syntax and the *semantics*) to add functionality, rather
than having a syntax-only spec and leaving implementors to guess semantics
for things (or give up and shrug when they encounter stuff that makes no
sense to them)?
[tight binding]
> The point
> is that
> it also has its disadvantages: fragility across time,
Yeah! ASCII, DNS, TCP/IP and all those other tightly defined binary protocols
just need to be rewritten every year, don't they?
> non-portability
> across systems
> (e.g. with different conceptions of dates and integers),
That's not true! Any Turing-complete processing device can convert between
reasonable agreed interchange formats and whatever in-memory representation
the implementation wants to use, don't be silly.
> dependence on a
> single
> vendor, etc......
God yes, Microsoft are making a *killing* on owning the only TCP/IP
implementation in the world.
> all those things that XML was supposed to take us away
> from!
Hmmf!
ABS
--
A city is like a large, complex, rabbit
- ARP
|
