RE: Impact of XML on Data Modeling

The main argument against using XSD for modelling is that it forces you to
make decisions which you don't really want to make at the modelling stage -
decisions about elements versus attributes, decisions about partitioning the
design into namespaces, decisions about whether A should restrict B or
whether B should extend A, decisions about which elements/types should be
global.
 
Most importantly, XSD (and indeed XML itself) provides no machinery for
discussing relationships at a suitable level of abstraction. There's a
ragbag of mechanisms for handling relationships in XML - the parent/child
hierarchy, ID/IDREF, hrefs and URIs, application-defined keys and keyrefs.
Deciding which of these mechanisms to use to implement a particular
relationship definitely falls into the "logical design" space (as I define
it) rather than the modelling (or conceptual design) space. At the modelling
level you want to know that there's a one-to-many relationship between
customers and accounts; whether that turns into a parent-child relationship
in the XML of a particular message is of concern only to the designers (and
consumers) of that particular message.
 
Michael Kay
http://www.saxonica.com/


  _____  

From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Tsao, Scott
Sent: 30 January 2008 19:47
To: David Ezell
Cc: xmlschema-dev@w3.org
Subject: 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