[
Lists Home |
Date Index |
Thread Index
]
5/17/02 9:59:51 AM, Uche Ogbuji <uche.ogbuji@fourthought.com> wrote:
>I think this is the crux of my disagreement with your position (which I understand to be that of
much of the static-types-in-XML supporters). Amy Lewis nailed it when she suggested that the
proper way to think of data types is against the problem domain, not the implementation language.
Worrying about how to faithfully reproduce, say, an unsigned int type interoperably is very
backward when it is very likely that the equivalent value in your real world problem *truly*
follows a constraint of 0 to 2^32.
In "publishing" or "document-oriented" scenarios, we often talk about using markup to describe the
structure of one's information rather than the details of how it should be presented. I think what
you're getting at is that we need to draw a similar distinction in "data-oriented" scenarios; just
as document-oriented markup shouldn't concern itself with the details of rendering, data-oriented
markup shouldn't concern itself with the internal implementation details of the application that
processes the data, such as how the application maps the data into bits. It's the "logical
markup" versus "physical markup" distinction. Another way to put it is that changing the way an
application maps a particular piece of data into storage bits should *not* require any change to
the schema.
AFAICT, the only loss from this view is that you can't write an application that reads a schema and
automatically generates the most efficient possible programming-language class definitions for the
data described by that schema. But as has been alluded to before, you can't do that anyway unless
the primitive types available in the schema language correspond exactly to those in the programming
language. And isn't this use of a schema just another case of wanting the schema language to do
everything including washing the dishes? Wouldn't it make more sense to have another language that
would allow you to write specifications that a class generator could use in conjunction with a
schema, rather than requiring all schema processors to do things that are only useful for class
generators?
There's a principle of genetics known as Fisher's Fundamental Theorem of Natural Selection (after
Sir Ronald Fisher) which states that the better adapted an organism is to its current environment,
the less of a change in its environment it can survive. Gerald Weinberg has observed that this
applies to human inventions as much as to natural organisms, and it particularly applies to
programs and the systems they're part of. Markup that's tightly coupled to the internal
implementation details of its processors may use fewer CPU cycles (cheap, can throw more hardware
at the problem) but is more likely to need rework (expensive, throwing more people at the problem
seldom works) if the implementation changes. Tying in with another thread, I've seen people decide
whether to represent something as an attribute or an element by measuring which a particular parser
parses faster! That's a decision that could easily be rendered incorrect by a newer version of the
parser, let alone moving to another parser.
|
