Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Objections to / uses of PSVI?
 5/17/02 9:59:51 AM, Uche Ogbuji <uche.ogbuji@f...> 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
