[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: building an object model of a XML schema
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Michael Brennan <Michael_Brennan@allegis.com>,Ronald Bourret <firstname.lastname@example.org>
- Date: Wed, 11 Jul 2001 16:07:12 -0500
Note that I am a fan of object-modeling and
object-oriented systems, particularly hybrids
for very large implementations. Still, some
initiatives don't depend on implementation or
if they do, leave the object model to the industry.
The assumption is that an application exists or is
about to be designed such that one object model should
be defined. It isn't always the case. On the other
hand, that is what UML is for so this may simply
mean UML is the wrong tool.
Data-centric design doesn't *of necessity* work like that.
There are many data designs that clearly and unambiguously
state the data, types, lengths, validation rules,
etc. but do not imply a processing model or set
of operations. These are typically for sharing
among systems that are semantically loose. They
result in core-stable/locally-customized implementations.
That was and probably still is more typical of document
designs, but not all are documents. I can site Federal
standards for example, that rely on prose descriptions
which would be easily translated into something like
XML Schema + Schematron but to imply an object model
with operations would be to imply implementation and
therefore, would be unacceptable.
For that kind of system, one might define in the UML
a set of grouping concepts that actually never occur
in the data. So, does the case still hold? The case
is when a data standard or spec is designed but no
implementation. In other words, in the spirit of
doing less, UML may not be the place to start.
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
Sent: Wednesday, July 11, 2001 3:56 PM
To: Bullard, Claude L (Len); Ronald Bourret
Subject: RE: building an object model of a XML schema
> From: Bullard, Claude L (Len) [mailto:email@example.com]
> What if the idea is that the XML Schema is a set of reusable
> types, a toolkit that is then included/imported/redefined/substituted
> into other application languages? I also haven't
> exported a schema out of UML, but it seems to me it
> may include classes that such a design would not use.
I've thought about this one, myself. I'm in general agreement with Ronald
Bourret. I believe in defining the object model or data model used by the
application in a manner that suits the needs of the application. The XML
document model should be separate, and an appropriate mapping defined
between them. The XML can then just be treated as a serialization format or
command syntax (or both, in our case). The mapping need not be monolithic,
though. If you have reusable types in your application's object model, and
reusable structures in your XML documents that have some meaningful
correlation to types in your object model, than why not have mappings
between the two as reusable modules that can be used by other mapping
That's the tack I'm trying to take now with our integration toolset, though
I haven't gotten very far in implementation, yet.
Note that we don't mechanically generate schemas from UML models. That
approach is suitable for some purposes, but we define the two independently,
then define a mapping between the two.