[
Lists Home |
Date Index |
Thread Index
]
> 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.
Largely, yes.
> 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.
Yes. This is why I mentioned that the current drive for XML Grand Unified Types is probably driven by users who live and die by shiny GUIs.
Disclaimer: I have no problem with shiny GUIs perse. But in too many cases they mask colossal conceptual problems.
> 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.
Yes. Shiny GUIs paper over this by making best guesses for you. Perhaps one or two will have an advanced option for selecting a bit more broadly from simple types. Perhaps some will even let you twiddle with facets. But there are band-aids on a severed limb.
> 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?
Bingo.
> 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.
Quite.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web - http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
|
