[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schema as a data modeling tool

  • From: Hans-Juergen Rennau <hrennau@yahoo.de>
  • To: Michael Kay <mike@saxonica.com>
  • Date: Mon, 30 Sep 2013 12:48:16 +0100 (BST)

Re:  XML Schema as a data modeling tool
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@y...>
CC: "xml-dev@l..." <xml-dev@l...>
Gesendet: 10:54 Montag, 30.September 2013
Betreff: Re: 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.