[
Lists Home |
Date Index |
Thread Index
]
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Tim Bray writes:
> >Michael Kay wrote:
> >
> >> The problem is that it should have an underlying model, but it
> >> hasn't:
> >
> >I couldn't disagree more. Defining the syntax without the underlying
> >data model *maximizes* interoperability because it reduces the number
> >of shared assumptions. The notion that two organizations will share
> >the data model for a purchase order or a bill of materials is just
> >silly, but they can often deal with each others' serialized output.
> >The evidence in the field is overwhelmingly on my side.
I think there's some blurring of the term 'data model' in this argument, so
I find myself
agreeing and disagreeing with it simultaneously.
I know you all know this, but let's have some loose definitions for
clarity's sake:
The term 'data model' is frequently used in two contexts. The formal use of
the term refers to how data (any data) is stuctured logically. Hence, you
have relational data models, hierarchical data models, flat files, etc.
XML has a flexible enough syntax that it would be hard to categorize it as
representing one particular data structure, although it does lend itself
readily to hierarchical data structures. I agree with the "XML has no data
model" statement, as much as I can agree that "C has no data model", or even
"SQL has no data model".
A second use of the term is more properly called a _user's_ data model, or
sometimes "conceptual data model". This is how domain data is _perceived_
by the user to be structured. It has nothing to do with physical
representation. One should be able to map any user data model to just about
any physical one, although a particular physical layout may be preferred
dependent on the nature of the user model and the computing system it
operates under.
It is silly to assume that two independent organizations will have the same
user's data model. People perceive data according to how their business
functions. However, it's silly not to suppose that a successful exchange of
data requires some shared semantics. You can operate with mismatch
assumptions about exchanged data for only so long before dissonance between
the differing cogitive models bites and bites hard. Assumptions are risky.
If two parties can agree to an enforeable contract, then it should be
preferred.
> Unfortunately, standardizing only syntax can hide religious claims
> behind a veneer of "but it's a standard", as is so painfully the case
> with URIs and anything so unfortunate to use them only as identifiers.
> Syntax standardization also seems to embolden people to go out and
> standardize meanings and processing, which brings them right into the
> weeds.
Yep. But I think one can distinguish between "building upon a shared
standard" and "exchanging information conformant to a shared standard". My
organization maybe required to produce Job Definition Format documents
(defined by a 40k XML Schema), but I have argued vehemently about using this
document's data model internally. It's more sensible to map our internal
user data models to the 'shared' JDF structure before exchanging data,
precisely for the reasons Simon and Tims state.
> XML has demonstrated that agreement on syntax across a wide range of
> information representation fields is both possible and useful, and
> that's new and interesting.
Yep. XML has nice flexibility, readability, and most user models are by and
large mappable to XML hierarchies+.
> >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 agree completely now, though I probably disagreed back when you were
> making the decision. (Sometimes it's much better that I'm not
> involved!)
|
