Thank you, Michael. You wrote "It [XSD] is a hierarchic model, whereas the real world is a network." I would say, it is as much a network as it is hierarchic. Think of economic structures (e.g. a shop inventory), of administrative structures (a registration procedure), of biological structures (a cell). At any rate the structures I have been dealing with were usually hierarchic, unwieldy and confusing if not dealt with as such, and often straightforward to handle, otherwise. I could show you an ER diagram representing over 100 relational tables storing shopping cart data, and also a single tree representation which can be read like a newspaper. A concise tree representation can be read like a
text, conveying a sense of the whole. An ER diagram with many boxes and very many lines is very hard to read. Doubtless you are right in warning about the problems how to model relationships which do not correspond to containment. But I wonder - would you really suggest giving up the benefits of hierarchical modelling, and what is the alternative? You know the German saying, "Not to see the wood because of all those trees", which I suggest to invert, not to see the trees, because they are part of a wood.
And then I am unsure in how far your argument applies to XSD specifically, or to XML in general, that is, to models based on
node trees and constraints on those trees. You assert that XSD is designed for representing messages, and I think the core of that statement is that XSD is restricted to contemplating *isolated* documents, rather than systems of documents, right? (So XSD is perhaps not really message-minded, but just single-document-minded.) But probably you would not say that this limitation applies to the XML node model itself. Or would you say that it is an intrinsic feature of node models not to cope well with relationships? I cannot see any reason why - relational databases use columns to contain foreign keys, is that better than using attributes or elements to contain an equivalent of a foreign key?
But if your warnings apply to XSD, rather than to XML, we might shift the emphasis: regarding XSD as a mere tool for XML modelling (a tool the limitations of which you emphasize) and be careful not to confuse it with XML modelling as such. I do not think that XML modelling stands and falls with XSD's capacity to express it fully. (Interestingly, NIEM asserts the equivalence of reference and containment (from the referencing point of view), which is of course completely opposed to the viewpoint of XSD.)
Concerning the relationship between
a reference model and message design, I wonder how to fight inconsistencies in naming and structure without some kind of common reference.
Hans-Juergen
PS: Concerning the example of the salary history, I find the NIEM concept of augmentation quite interesting.
Von: Michael Kay <mike@saxonica.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>
CC: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 10:54 Montag, 30.September 2013
Betreff: Re: [xml-dev] XML Schema as a data modeling tool
Well, let me start by pointing out the drawbacks, seen very severely on a project I did some consultancy for, where they had indeed used XML Schema for a large scale enterprise data model:
(A) XSD isn't very good at modelling relationships. It's a hierarchic model, whereas the real world is a network. Modelling relationships other than aggregations therefore involves some arbitrary decisions on representation, which you don't really want in a conceptual data
model.
(B) XSD is designed for representing messages rather than for creating an enterprise data model, and it's very easy to get the two confused. It might be that every employee has a salary history, but that doesn't mean the salary history has to be part of every message concerning the employee. The relationship between the conceptual reference model and the design of individual messages can be quite indirect. There are really several separate problems here: (a) XSD was designed for message/document design, not for conceptual modelling, (b) designing a family of schemas for a large set of message types, with reuse of components across all the message types, is itself rather difficult and there's very little in XSD that makes it easier, (c) message design has to take the process model into account, not just the data model.
Michael Kay
Saxonica
