[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: building an object model of a XML schema
- From: Jeff Lowery <email@example.com>
- To: 'Michael Brennan' <Michael_Brennan@allegis.com>,"'Bullard, Claude L (Len)'" <firstname.lastname@example.org>,Ronald Bourret <email@example.com>
- Date: Fri, 13 Jul 2001 13:44:37 -0700
If I look at XML Schema, I see type definitions that are largely
translatable to a sizeable chunk of program code. But XML Schema is, after
all, designed around a specific physical representation, so one has to agree
with Ron's assertion that object model generation from XML Schema has some
problems. On the other hand, object model to XML Schema generation has
problems, also, not the least of which is that many of the constraints
defined in the object model are operationally based, which doesn't lend them
to expression in XML Schema form (the number of ways to express certain data
constraints in an object model are literally infinite, as any Obfuscated C
contest will attest; not so infinite in XML Schema, however).
On the other hand, XML Schema is darn close, probably due more to its SOX
roots than intentional design. Tantalizingly close. My UML knowledge is
rusty, but I would think it's overkill for data models. What would I,
long-term writer of that crufty stuff that goes between application and
database or application and XML document, need to make my life easier?
Well, darn it, I want a data model (just data, thank you) that I can express
as a physical model through some tranformation, and as a set of objects
through another transformation. For the general class of data models, I
would expect the problem to be hard. For hierarchical data models only, I
think the problem is much easier, but not simple.
One thing is that I'm missing, in a conceptual data model, the necessary
information to build an optimal physical model. I may want a set of
elements, for example, to be stored in a hash map, keyed by some attribute
value. But hashmaps imply methods, not something for a data model. Hmmm...
You could take the approach of JAXB, and create an object binding schema in
addition to the data schema. You could take Castor's approach, which is (if
I remember) a property list with binding information.
Or maybe one could come up with a data model with types rich enough to serve
both masters. A hash map is, after all, a type that is universally
understood, it's just not a datatype, because it needs methods to work.
Maybe it could be called an archetype. Are there enough conceptual
archetypes that would provide enough information to allow generation of
efficient object model representations? I would think so, STL and
classes.zip has a bunch identified. The problem then becomes: can I easily
map datatypes to archetypes? If so, I can then build a upon whatever object
code is generated by the conceptual model, and the constraints will be
identical to those in my data model.
Ouch. Now I have a headache...