[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)" <clbullar@ingr.com>
- To: Amit Bhatiani <amit@invertica.com>, Ronald Bourret <rpbourret@rpbourret.com>
- Date: Wed, 11 Jul 2001 08:11:14 -0500
True for objects. Not quite so clear cut
in data-centric design. One has to think
of systems that are not one-offs or single
installation systems. One has to remember
why we have data standards for very large
data pipelines instead of object-standards.
Otherwise, yes.
Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
-----Original Message-----
From: Amit Bhatiani [mailto:amit@invertica.com]
Sent: Tuesday, July 10, 2001 5:49 PM
To: Ronald Bourret; Bullard, Claude L (Len)
Cc: xml-dev@lists.xml.org
Subject: RE: building an object model of a XML schema
> "Bullard, Claude L (Len)" wrote:
> >
> > An excellent paper, BTW.
> >
> > In it, you suggest that it is better NOT to
> > generate classes from XML Schemas. It is better use
> > a data modeling language such as UML and generate the
> > schema from that. Do you still support that position?
>
> Yes, although it's based on theoretical work, not real-world experience.
>
> XML Schemas are designed to model XML documents, not objects.
> Consequently, you get some weirdnesses when trying to map the schema
> data model to an object model. If your application really thinks in
> terms of objects, better to start with an object/generic modelling
> language and go the other direction. That way, the XML schema is just a
> serialization syntax, not a model.
>
I can give you some real-world reasons why you should start with objects and
not schemas.
1. As business requirements change, they require both data and behavior
changes. This obviously means that you design, code and test your changes in
the object model. This means you want the object model to be your ongoing
starting point, not the schema.
2. Expressing type constraints in the xml schema is cumbersome at best.
Strong type checking is important in most application scenarios.