Design Patterns in XML Applications: Part II
by Fabio Arciniegas A. | Pages: 1, 2, 3, 4, 5, 6

XML Patterns in DTD structure

Table of Contents

•Introduction •XMLable Pattern •Patterns in DTD Structures •Patterns in Element Definitions •A Little Advice •References

These patterns are named solutions to recurring problems in the overall structure of document types. Note that the term DTD here is applied in the sense of document type definition. These patterns are not restricted to any given form of XML schema definition.

DTD structure patterns are usually smaller than application design patterns. Therefore, two examples will be presented. For more information, see the links in the resources section.

Choice Reducing Container

Originator: Toivo Lainevool

Synopsis

When creating large DTDs with many logical units, authors might be required to learn a large number of these units to know how to use the DTD. Reducing the number of choices the author has to make at any point in the DTD (by grouping related elements beneath newly introduced elements) will reduce the burden on the author.

Context

In a DTD with many logical units, a user of a document can be overwhelmed with the number of choices that have to be made. With many options users have a difficult time knowing how to compose all of the elements available. This is common in large, general-purpose DTDs where many logical units are presented.

Forces

• Either because of the nature of the data to be represented, or because of the intention of making the DTD applicable in many situations, large numbers of logical units need to appear in the DTD.
• Several of the elements can be naturally grouped as members of a higher abstraction (e.g., "magnolia" and "rose" under "flowers").
• The learning process of the user wants to be simplified, presenting him or her with a small number of choices at each point.

Example

Here is a DTD fragment that presents a lot of choice to the author:

<!ELEMENT Doc (Para | OrderedList | UnorderedList | Figure
                | Artwork )+>

Here the author has 5 different elements to choose from after creating the doc element. This choice could be limited by introducing new elements, and grouping some of the existing elements together as children of the new elements, like this:

<!ELEMENT Doc (Para | List | Illustration )+)>
<!ELEMENT List (OrderedList | UnorderedList )>
<!ELEMENT Illustration (Figure | Artwork )>

Cross-Cutting Metadata

Also known as "Factoring Metadata"

Originator: Fabio Arciniegas A.

Synopsis

During the definition of a DTD, it is not unusual to find several elements sharing a common set of metadata needs. The Cross-Cutting Metadata Pattern identifies such common subsets and encapsulates them, in order to make a clearer DTD.

Context

Elements often have associated metadata (e.g., a unique identifier). Furthermore, many elements can share the same metadata needs. This is often the case in DTDs for element collections. Suppose you are developing a DTD for the items of a music and video shop. Your items, represented as elements, are bound to have many metadata needs in common: an identifier, an availability status, or maybe a recommendation status. The structure proposed by the Cross-Cutting Metadata Pattern is to encapsulate these common metadata needs (very often in a parameter entity), leading to a better organized and more maintainable DTD.

Forces

The needs that lead to the use of this pattern are straightforward:

• There are a number of elements that have metadata requirements.
• These elements share a subset of those requirements.
• The number of elements and the size of the subset are big enough to make the inclusion of a parameter entity (or an attribute group in XML: Schema) an improvement in readability and maintainability, instead of adding "bloat." For example, if there are only 2 elements, and the only thing they share is ID, introducing an extra construct is not an improvement.

Solution

Cross-Cutting Metadata takes the common subset of metadata needs and expresses it in whatever mechanism the schema definition language provides for encapsulation (e.g., parameter entities in XML DTDs). It then includes this construct in all the elements that share it. The pattern simply factors the metadata out of several elements. Even though metadata is often expressed in attributes, the pattern can also be applied if the metadata is in the form of elements.

Consequences

• Common metadata is easier to localize, and thus easier to modify.
• When applied to a large number of elements, readability is greatly improved.
• Reusability of metadata declarations is easier to achieve.

Example

This simple example deals with the music and video store DTD mentioned above. Consider the initial declarations:

<!ATTLIST video 
                id             ID      #REQUIRED
                available      (yes|no|onrequest)  "onrequest"
                onSale         CDATA   #FIXED "yes">

<!ATTLIST CD
                id             ID      #REQUIRED
                available      (yes|no|onrequest)  "yes"
                recommendation CDATA   #IMPLIED >

From these declarations we can derive a parameter entity using the Cross-Cutting Metedata pattern:

<!ENTITY % cross-cutting-metadata "
         id             ID      #REQUIRED
         available   (yes|no|onrequest) onrequest"
>

<!ATTLIST video 
          %cross-cutting-metadata;
          onSale         CDATA   #FIXED "yes"
>

<!ATTLIST cd
          %cross-cutting-metadata;
          recommendation CDATA   #IMPLIED 
>

We can then simply include this entity in all the element declarations that share them.

Not only has readability improved, but maintainability is higher as well. Now, when we need to add additional metadata to each element (e.g., "onSale"), we can easily and safely add it without enduring the error-prone process of including it manually on each element type.

Pages: 1, 2, 3, 4, 5, 6

Next Page