Re: building an object model of a XML schema

["Thomas B. Passin" <tpassin@home.com>]

[Jeff Lowery]


> Yeah, I think I said something about removing the XML-ness from XML Schema
> to derive this new schema language, then add in some OO archetypes (types
> with well-understood implicit behaviors BUT NO INTERFACE AND NO
> IMPLEMENTATION!!! -- thats up to the code generator).
>

I'm going to go out on a limb here (except I'm in good company) and claim
that if there is no interface, there IS NO type so far as O-O is concerned.
Two classes could easily have the same attributes and yet be so incompatible
that one could not even be cast to the other.  Conversely, many people say
the the interface IS the type.  That would be strictly the case if all
attributes were wrapped in accessor functions with no other access
permitted.  On the other hand, the type of a thing in a relational database
is essentially the column header for the table (whether created by a query,
a base table, or whatever) - you have to allow the header cells to include
the datatype as well as the name, I think, to be complete.

If you consider a class to have two parts - the data part and the
interface - you could match types as specified by xml-schema to the data
part, and you could have code that automatically creates such data-only
classes and fills the fields form an xml document.  But xml-schema has
nothing directly to say about their behavior.

So are you thinking of data-only classes, or what? And when you say
"removing the XML-ness from XML Schema", do you mean express the same things
but in a non-xml language, or do you mean to use an xml language but not to
express parts of the xml infoset?

Cheers,

Tom P