xml-dev - Re: Schema concepts

["Bill la Forge" <b.laforge@jxml.com>]

From: Jeff Lowery <jlowery@scenicsoft.com>
> 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@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************