You are certainly right that XSD is a problematic resource, when it comes to its consumption. But an XSD implies an unambiguous tree structure, and it is a concise representation of that tree structure what should be dropped on your manger's desk. And I can tell you from experience that managers like - and start to demand - concise tree representations, because they have rarely seen so expressive and intuitive representations of complex information.
I suppose we are thinking of different scales - yours may be larger than mine, and perhaps we are both "right" in the context we tacitly assume. I think primarily of self-contained entities (like a shopping cart, or a protein), and you think perhaps system views composed of many independent entities. It pleases me to think that our views might be complementary, rather than contradictory.
Hans-Juergen
Von: Peter Hunsberger <peter.hunsberger@gmail.com>
An: Hans-Juergen Rennau <hrennau@yahoo.de>
CC: Michael Kay <mike@saxonica.com>; "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
Gesendet: 17:00 Montag, 30.September 2013
Betreff: Re: [xml-dev] XML Schema as a data modeling tool
On Mon, Sep 30, 2013 at 6:48 AM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:You can make the same argument with conventional ER diagrams: decompose them into groups and you get simplification that people can understand. The problem isn't the ER diagrams, it's the presentation of them. XML Schema is, IMO, probably worse for that than a conventional ER diagram. A logical schema diagram with boxes with names on them and arrows pointing between the boxes is something I can drop on a managers desk. A XSD document, not so much so.
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.
However, in the end, trees, networks, what have you are all part of the larger problem called graph traversal. There are many, many, ways to deal with graph complexity and extracting relevant levels of detail from a graph. These days, if I was to look for a general approach for storing my model metadata and manipulating it, I would use a graph database. I see that being useful to generate XSD or an ER diagram and there are visualization tools that let you partition and examine portions of the graph on the fly...