RE: building an object model of a XML schema

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@allegis.com]
Sent: Wednesday, July 11, 2001 3:56 PM
To: Bullard, Claude L (Len); Ronald Bourret
Cc: xml-dev@lists.xml.org
Subject: RE: building an object model of a XML schema


> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]

<snip/>

> 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
modules?

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.