Modeler:8/XML Schema

To fully understand the relation between a conceptual model in CaseTalk and the XSD it can produce requires some in depth insight.

Network structured model

CaseTalk models the conceptual model similar to a network structure. The databases it can generate are also network like structures. A table can refer to multiple other tables, and they in turn can reference back to the originating root table. This is in contrast to a typical XML message structure which is mostly hierarchical in nature. A root element contains child elements and they in turn can contain child elements.

XSD building blocks

In XSD both building blocks are defined as the structure in which the final XML elements are to be presented. The building blocks consist of Simple Types and Complex Types. They are roughly comparable to Database Domains and Database Tables, or Class Attributes and Class Types.

An example showing the "Order" from the a generated XSD from model Working Hours:

XML Message

The final XML messages to be used to exchange structured information should follow a strictly defined structure. This structure can be defined in XML using "element" notations. This structure can depend on the message to be exchanged. They also vary depending on the information needs, similar to a SQL Query which can vary independently of the underlying Database structure.

Example

A brief example to illustrate the possible messages, although they communicate similar entities and identifications:

• A sensor (with number 627) measures on a day (1-1-2014) the weight (10000KG) of a train (with train number 9876).
• A sensor (with number 627) measures on a day (1-1-2014) the weight (11000KG) of a train (with train number 6478).
• A sensor (with number 627) measures on a day (2-1-2014) the weight (9000KG) of a train (with train number 8265).
• A sensor (with number 627) measures on a day (2-1-2014) the weight (17000KG) of a train (with train number 3345).

These may be presented in an XML message like such:

 <Sensor id="627">
   <Day date="1-1-2014">
     <Train number="9876" weight="10000"/>
     <Train number="6478" weight="11000"/>
   </Dag>
   <Day date="2-1-2014">
     <Train number="8265" weight="9000"/>
     <Train number="3345" weight="17000"/>
   </Day>
 </Sensor>

But with similar information a completely different message might be appropriate, where not the sensor but the train itself is the root of our message:

 <Train id="9876">
   <Day date="1-1-2014">
     <Sensor id="627" weight="10000"/>
     <Sensor id="628" weight="10001"/>
     <Sensor id="629" weight="10002"/>
   </Day>
   <Day date="2-1-2014">
     <Sensor id="627" weight="9999"/>
     <Sensor id="628" weight="9998"/>
     <Sensor id="629" weight="9997"/>
   </Day>
 </Train>

The examples above illustrate that identification structure and element relations are independent from the representation or reporting.

Additional Design efforts

CaseTalk can therefor only generate a XSD file containing all simple and complex types, directly derived from the conceptual model, but never the relations between the typed elements in which a future XML should be set up. It is up to the developer/architect to construct a meaningful element structure based upon the simple and complex types generated by CaseTalk.

Background

The information in the XSD follows the structure as described on this webpage: [1]

To make a final clarification, XSD's can be written in numerous manners. The w3schools contain a clear example and CaseTalk uses the last notation manner illustrated on this page: [2]

Conclusion

The information models in CaseTalk remain essential to document and structure the conceptual models. How than the information is reported, presented or used is up to further design and influenced by the actual information needs. Tools like Altova's XmlSpy or Sparkx Enterprise Architect remain useful to assemble the final message structure after generating the conceptual list and documentation from CaseTalk.