Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Objections to / uses of PSVI?
 > 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 
|
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
|
|||||||||
