OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Objections to / uses of PSVI?

[ 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 

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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS