It All Starts With Data

Table of Contents Data Model Data Definition Using an XML Schema for Data Definitions Tree Root Element Topics in this section

Application data can be described by a model of data types that shows hierarchical relationships including a root type, and defined in a format, such as an XML Schema, that can be saved in a type definition file.

Nearly all applications work with data of some sort: text, art work, timelines, circuits, and so on. Creating this data is the main purpose of most applications — data is central and vital. Once you create data, you want to save it — and then get it back later to work on some more, editing what you have already crafted and adding to it. Application data is the DOM's bailiwick. This section discusses how the various DOM features aid in handling application data. The term DOM refers not only to the DOM framework, but to data following this model.

Data Model

Unless your application is working with some previously defined (and perhaps standard) data format, one of the first things you do in developing an application is to create a model for your data. You need to explore what your application does and produces in terms of its end product — the application data.

What is this data made up of? That is, how can you decompose it into primitive data types: integers, floating point numbers, Booleans, binary streams, and so on? And how are these primitive types assembled? Are they placed into lists or other data structures?

Some data types are very simple, represented by a single value. For instance, a name type can be represented by a string.

More complex data types have attributes. For example, a type representing a rectangle could have a width, height, and x- and y-coordinates for its upper left corner, each value a floating point number.

There is usually a hierarchy of data types. Data can be hierarchical in a couple of ways:

• Data can contain other data. For instance, a folder can contain other objects, including other folders.
• Data types can be refinements of each other, that is, data types inherit from other data types. For example, a rectangle is a type of polygon, so a rectangle type is based on a polygon type.

Data Definition

In the process of developing the application's data model, you precisely specify the model in some data definition language. You save this definition in a type definition file.

By default, ATF supports the XML Schema Definition (XSD) language, or XML Schema for short, as the type definition language to describe the application's data model. This language allows you to specify the data types that are used in application data. You can describe the type's attributes, the primitive types of data in types, what type of elements of other types can be contained in the type, which type this type is based on, restrictions on the data, and so on. The language itself is in XML.

You can also use a type definition language other than XML schema to describe your data model (DDL, IDL, or custom languages). You can use the ATF DOM without using an XML Schema, but you will have more work to do. For information on XML schema concepts, see the W3Schools tutorial on XSD at XML Schema Tutorial.

Following the object-oriented paradigm, you generally define a type for each kind of object in your application data. Every DomNode has one of these types.

Using an XML Schema for Data Definitions

Generally, an XML Schema is used to describe the structure of an XML document. ATF uses an XML Schema to indicate the types in an application's data — rather than an XML document's structure. Hence, ATF applications' XML Schemas mainly consist of type definitions.

Although XML Schemas allow defining simple types with the <xs:simpleType> element, in practice, simple types are used only to specify special types such as enumerations and lists. You can also use a simple type to describe a type with a restriction, such as being bounded by certain values. Most types used in ATF XML Schemas are complex, using the <xs:complexType> element, with at least one attribute.

The key items your definition needs to specify for each type are:

• What type, if any, is this type based on? XML Schema uses the <xs:extension> tag for this.
• What attributes does the type have? The XML Schema tag is <xs:attribute>.
• Can an object of this type have child objects of a certain type? Use the <xs:sequence> and <xs:element> tags to specify children.
• What are the primitive types used for elements in this type?

Here are some examples of types used in the ATF Using Dom Sample from its games.xsd type definition file. This definition of a "gameObjectType" specifies one "name" attribute with the type "xs:ID". The ID type, usually unique, is used to identify the game object:

<xs:complexType name="gameObjectType">
  <xs:attribute name="name" type="xs:ID" />
</xs:complexType>

The "gameObjectType" has only piece of information: its "name" attribute as the primitive ID type ("xs:ID"). This is generally what type definitions look like — for types having only one data item associated with them.

This "ogreType" definition is based on the "gameObjectType" and has two attributes:

<xs:complexType name="ogreType">
  <xs:complexContent>
    <xs:extension base="gameObjectType">
      <xs:attribute name="size" type="xs:integer"/>
      <xs:attribute name="strength" type="xs:integer"/>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

The <xs:extension base="gameObjectType"> element indicates that the type is based on "gameObjectType", shown previously. Both its attributes "size" and "strength" are integers.

The other form of hierarchy is containment, which is demonstrated by "gameType":

<xs:complexType name="gameType">
  <xs:sequence>
    <xs:element name="gameObject" type="gameObjectType" minOccurs="0" maxOccurs="unbounded" />
  </xs:sequence>
  <xs:attribute name="name" type="xs:ID"/>
</xs:complexType>

The element <xs:sequence> starts a list of <xs:element> elements indicating the types of objects that an object of the parent type can contain. The type "gameType" can contain any number of "gameObjectType" child objects, as indicated by minOccurs="0" maxOccurs="unbounded" in <xs:element>. These child types can include the "ogreType" just defined, because "ogreType" is a "gameObjectType". The "gameType" type also has a "name" attribute, which is an ID type.

Tree Root Element

The ATF DOM stores data as a tree of DomNodes, each DomNode having one of the defined types. The tree generally has only one root, although you can have more than one. The type of the root is obviously defined so that objects of its type contain other elements. In turn, the root's child nodes can be subtrees, containing various types of objects.

The ATF Using Dom Sample's root element is of type "gameType" and is defined this way:

<xs:element name="game" type="gameType"/>

ATF XML Schema files use the <xs:element> element standing by itself to define the root object.

The UsingDom sample has a very simple data structure: it has only one root and its children are all "gameObjectType" objects, which do not have children themselves.

As will be seen in subsequent sections, the type of the root element is very important. For example, events monitored on a node are generally also monitored on all of its child nodes. And these event listeners, which are DOM adapters, are specified on the type of the node.

Topics in this section