Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Schema concepts
 From: Jeff Lowery <jlowery@s...> > What the type/element distinction potentially makes easy, IMO, is a sloppy > and convoluted taxonomy of objects (to say "this [XML-Schema] is not OOP" is > a half-truth: it is an attempt at a superset of OOP inheritance concepts > minus methods and v-tables). What it allows is a seperate inheritance graph > for type and elements-- does that really make sense? Aren't is-a and has-a > related more often than not? If an element is sharing a type definition > with another element, isn't also sharing something more fundamental, some > abstraction that encompasses not only the shared type, but also common > business rules and methods that are defined, not in the schema, but in the > application that uses the schema? > > Since, in order to be useful, a schema must have methods for it's elements, > and those methods reside in an OOP application, is breaking the type/element > distinction really have any utility since all those elements and types have > to be mapped to a classic OOP hierarchy, anyway? If we could map type definitions to implementation, there might be some sense to all this. But I expect the ability to extend element content would preclude this. For me, the crux of the matter isn't in the development of parsers that can validate XML Schema, but in developing appropriate technology to bind schemas and implementations. And while there might be some agreement that XML Schema is simplly too rich for its own good, I expect that it would be difficult to develop wide agreement on the features which are worth keeping. One answer might be to develop, yes, yet another specification, that would define how the bindings could be done. Of course, that then opens the door to another debate--is the JSR 031 approach adequate? Or can we allow the programmer to specify the internal representations? I really think the way to resolve XML Schema complexity issues is to drill down on the binding issues. (I've recently participated in an off-list discussion about JSR 031 vs use of a binding schema like Quick uses. I found the JSR 031 proponents to be quite convinced, if not entirely convincing, that generating code from a schema was very much the correct approach. Their answer to having to use a bill-to address when no ship-to address is present was simply that the data representation should be dependent on type, not element. Of course, that answer requires an influence by the developer over the schema definition. And that answer does not, in my mind, address the problems a programmer will need to face when multiple markup languages result in multiple internal representations for effectively the same data.) Bill *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/threads.html *************************************************************************** 
|
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
|
|||||||||
