I think the term "data model" is used in at least three different ways: (a) a value space. For example, the set of all pairs of xs:double values in the range ((-180, +180), (-90, +90)). (b) a correspondence between values in that value space and something external ("the real world"): for example a correspondence between the values in (a) and points on the earth's surface, treating the two xs:double values as longitude and latitude. This correspondence enables us to attach meaning to the data, for example the existence of an element <empl first="John" last="Brown"/> implies the existence of an employee named John Brown. (c) a set of modelling constructs that can be used in describing data models of types (a) and (b). For example, the relational "data model" offers us tables, primary keys, and foreign keys; the Java data model offers us classes, interfaces, methods and fields. When we talk about an XML data model like XDM, we are primarily talking about (a). XDM describes the space of all possible XML documents (for example, the possibilities include elements with child text nodes, but they don't include attributes with child elements). But at the same time this provides a vocabulary for (b) and (c): once XDM is defined, we can start to exploit it by deciding, for example, to represent employees using elements named "empl" with attributes "first" and "last". It is this process that is often called "data modelling", and the output of the process is a schema which in effect defines a subset of the XDM (or relational) value space, namely the "valid instances" of our model, together with documentation that enable us to make connections between instances/sentences in the documents and external realities. Michael Kay Saxonica |