RE: building an object model of a XML schema

[Michael Brennan <Michael_Brennan@allegis.com>]

I agree. That's why we don't mechanically derive the XML Schema from our own
application's object model. The XML Schema is precisely (in our case) for
sharing among systems that are semantically loose (namely, those of our
customers and partners that need to integrate with ours). The object model
is for our own application's processing model of that XML, and is internal
to our own design and implementation effort. We don't exchange these latter
models with external parties; just the XML Schema, because that completely
defines our interface as far as any external party is concerned (although
adding the additional semantics that something like WSDL provides is useful,
and I suspect we will start using that at some point). This also allows us
the flexibility to use some third party XML Schema that has no corresponding
object model, and define the object model that suits our own use of that
document type.

I think starting with a UML model may make sense for groups or organizations
that are specifying a standard processing model (maybe as part of a
workflow, or trading relationship) in addition to data interchange
standards. Just specifying the data format is not enough in such cases. But
when you just want to specify data interchange, UML is the wrong tool, in my
opinion, though it is still useful for designing a particular application's
processing model for the relevant document type.

I should add that in many cases, we are not even exchanging true XML
Schemas. Those of our customers who are XML saavy and want an XML Schema can
have one; those who don't want schemas just get Word documents that describe
the schema in human readable prose.

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Wednesday, July 11, 2001 2:07 PM
> To: Michael Brennan; Ronald Bourret
> Cc: xml-dev@lists.xml.org
> Subject: RE: building an object model of a XML schema
> 
> 
> 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