xml-dev - RE: Schema concepts

["Jeff Lowery" <jlowery@scenicsoft.com>]

> This is not OOP.  <shipTo> and <billTo> are not subclasses of an
> <Address> element, they are elements which have necessarily identical
> content and attributes but are _not_ allowed wherever their parent
> would be.

I think this is the crux of the arguement for the type/element distinction.
Although I can see where this could be useful, it unsettles me a little.
Why? Because in my experience, whenever two definitions of two types are
similar but do not meet is-a criterion, it almost invariably means that
there exists a higher-level abstraction that encompasses the two types.

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?


***************************************************************************
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
***************************************************************************