- From: Michael Kay <mike@saxonica.com>
- Date: Wed, 30 Jan 2008 21:07:28 -0000
- To: "'Tsao, Scott'" <scott.tsao@boeing.com>, "'David Ezell'" <David_E3@VERIFONE.com>
- Cc: <xmlschema-dev@w3.org>
- Message-ID: <020a01c86384$1f24fdd0$6501a8c0@turtle>
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
Received on Wednesday, 30 January 2008 21:08:10 UTC