[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: building an object model of a XML schema
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@i...] > Sent: Wednesday, July 11, 2001 2:07 PM > To: Michael Brennan; Ronald Bourret > Cc: xml-dev@l... > 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|