RE: Impact of XML on Data Modeling

David,

I thought that it is about time that you might chime in :-)
 
I am not sure the REAL reasons why "XML Schema [XSD] is a definition
language, not a modeling language."  It seems to me that a modeling
'language'  (e.g., UML) provides a set of agreed-upon 'artifacts' for
human beings to graphically express and communicate their thoughts
(i.e., modeling concepts).  Since those artifacts are not one size fits
all (and will never be), a methodology such as the 3-schema architecture
is necessary so that people can sort of 'get on the same page' to
communicate and collaborate (e.g., in the 'relational' world, people may
use IDEF, ER, and UML to cover different perspectives).  However, the
unavoidable challenge is that one would have to map from one set of
artifacts to another set of artifacts, and ultimately to the code that
software can understand.
 
Now, as far as I understand, XSD seems to possess most of the necessary
'descriptive' capabilities to support those artifacts that human beings
need to communicate from their (different) perspectives.  If that is the
case, shouldn't we start in the reverse direction, i.e., (1) Look at the
'descriptive' capabilities of XSD one group at a time and determine what
kind of modeling concept they support; (2) Agree on the graphical
representation (i.e., artifact) for that particular modeling concept;
and (3) Encourage CASE tool vendors to provide usability features to
implement those artifacts on top of their tools (presumably already
support XSD).
 
Another thought is that, with the versioning capabilities of XSD 1.1,
would it be possible that the Conceptual - Logical - Physical modeling
can be done through evolving versions of basically the 'same' set of
schemas?
 
Please feel free to chime in.
 
Thanks,
 



Scott Tsao 
Associate Technical Fellow 
The Boeing Company 

 

Received on Wednesday, 30 January 2008 19:47:43 UTC