Lists Home |
Date 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.
> 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
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
> 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.
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