The success of an XML application depends on how the actual XML documents are used.They must not only carry information that is needed for communication, but they also need to be flexible enough to accommodate future requirements. This section looks into the various factors that are to be taken into account when designing XML document structures.

We will be concentrating on three areas of design process namely Information modeling which is about understanding the structure and meaning of information carried in documents. Secondly, Document design that describes translating information model into a set of rules or a schema for creating actual documents. In the end, Schema notations that are the techniques for recording the document design so that it is accessible to both processing software and human users.

The first rule in information modeling is to focus "real world" and not the technology. Information model is the description of information used in an organization, independent of any IT systems.

There are two objectives in an information modeling exercise to achieve absolute precise information and to communicate effectively with users.

There are two main types of information model namely static model and dynamic model.

Static models describe the permissible states of the system. They describe the types of objects in the system, their properties and their relationships. They also define the agreed names for these objects.

Dynamic models describe what happens to information. These models describe a set of information exchanges such as data that is sent from one place to another for a particular purpose.

In general, static models are related to the design of a database where information is stored for long periods to serve a variety of purposes, while dynamic models are related to the design of messages that have only transient existence and a very specific purpose.

The systematic approach in defining a static information model is naming, organizing, finding and defining things or objects.

The first step, a good way to start any information modeling is by establishing the names of things in the system. The "things" are generally referred to as Entities, Objects or Data objects. We will call them Object Types. It would be better to understand all these with the help of this HOLIDAY example. The definition of the term "holiday" needs to ensure that we can recognize a holiday when we see one and that there is no room for disputes about whether something is a holiday or not.

One could begin by preparing a list of things related to the system.

The next stage is to produce definitions of the object types.

As well as naming the object types at this stage, it is also worth thinking about the individual instances and how they will identify the instances.

Having listed and named the object types, we will now have to organize them into a hierarchical scheme. Often these hierarchical relationships will emerge while we are writing the definitions of the object types.
The key phrase is the "is a" test, as we always use "is a" for the relationship between an individual instance and its type. Identifying subtypes is useful in the document design stage. Here is the figure showing the type of hierarchy that we would use for the holiday business. It uses the UML notation, in which an arrow points from a sub-type to its super-type.

Having named the object types, the next stage in static information modeling is to determine relationships that exist among them.

The cardinality of a relationship describes how many of each kind of object can take part in the relationship.

	The most common kind is the one-to-many relationship such as one chapter may have many paragraphs.
	Many-to-many relationship can also occur such as one author may write several books or many authors may write one book.
	One-to-one relationship is less common; one example is the relationship between a person and a job.

In modeling information, a particularly important kind of relationship is the Contains relationship. This is always one-to-one or one-to-many. There is no hard and fast rule as to exactly what the constitution of the Contains relationship in.

There are two forms of Contains relationship namely aggregation, which is a loose assembly of objects to allow a group of things to be treated as a whole and composition, which is a much stronger relationship where the subtypes have no independent existence of their own.

As object types and relationship form the static information model, properties put the flesh on the bones. Properties are simply the values associated with the objects. A person has height, weight, nationality and an occupation.

The main thing that is to be known is the datatype - whether there is a fixed range of values, is it numeric, in what units is it measured, is it mandatory and is there a default value.

Instead of defining a step-a-step approach as in static modeling, we will just outline some of the techniques available. The techniques are Process and workflow models, Data flow models, Object models, Object life histories, Use cases and Object interaction diagrams.

The objective is to understand what the system is supposed to be doing. We only need to model the parts of the system that are causing difficulty, not the whole thing.

Process and Workflow models focus on the roles of people and organizations in getting work done; while the information stores and processing stages play a secondary role0.

The data flow models focus more on the information system rather than the business.

This model describes data stores where the information is stored, processors that manipulate the data and data flows that transfer data from one processor or data store to another. This relies very much on the static information model.

Object models have dynamic as well as static content. The dynamic or behavioral part of an object definition describes what each object can do as a set of operators or methods that define its actions.
Object life histories focus on the individual objects. They describe what happens to each object through its lifetime.

Use cases analyze how specific user tasks are accomplished. Use cases can be useful both in modeling the business and in describing the internal behavior of the IT system.

Object interaction diagrams analyze the exchange of messages between objects at a finer level of detail than the data flow model. While the data flow model might simply identify that the online bookings system sends transaction information to the credit card clearer and gets authorization in response, the interaction diagram will describe all the messages that make up this conversation in fine detail.