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 ]

> 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






 

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

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