XML Editor - Download a Free Trial >
See What's New >
Buy Now >

[Home] [By Thread] [By Date] [Recent Entries]

Outstanding discussion!  Thanks Christian for keeping me honest.  Every engineering decision has its pros and cons.  I failed to consider that in my original post.  So, I have completely rewritten my original post to (hopefully) reflect a more balanced perspective.  Have I fairly captured the pros and cons of the 3 issues I try to address?  /Roger

 

3 Things to Consider when Designing XML

 

Introduction

 

In this message I will discuss XML design with respect to these 3 things:

 

1.     Element relationships – implicit versus explicit.

2.     Element coupling – tight versus loose.

3.     Element structuring – nested (hierarchical) versus flat.

 

Which is Better Design?

 

Suppose that I have data about a grape vineyard.  Shown below are two lots on the vineyard, and a picker on one of the lots.  Two ways of designing the data are shown.  In this message I will address the issue: which design is better?

 

Version #1

 

<Lot id="1">

      <ripe-grapes>4</ripe-grapes>

      <Picker id="John">

            <metabolism>2</metabolism>

            <grape-wealth>20</grape-wealth>

      </Picker>

</Lot>

<Lot id="2">

      <ripe-grapes>3</ripe-grapes>

</Lot>

 

Version #2

 

<Lot id="1">

      <ripe-grapes>4</ripe-grapes>

</Lot>

<Lot id="2">

      <ripe-grapes>3</ripe-grapes>

</Lot>

<Picker id="John" locatedOn="1">

      <metabolism>2</metabolism>

      <grape-wealth>20</grape-wealth>

</Picker>

 

Question/Observations

 

Before proceeding with analysis, let me first ask a preliminary question, and make some observations:

 

1.     Question: How difficult is it for an application to process each version?

Example: Suppose that an application wants to move the Picker to Lot 2.  With which version would it be easier to do this? 

Example: Suppose that an application wants to find all Pickers on a Lot.  With which version would it be easier to do this?

2.     Observation: Both versions are comprised of two components:

- A Lot component.

- A Picker component.

3.     Observation: Both versions are modular.  Both represent the Picker as located on Lot 1.  They differ in how the information is physically represented. [An equivalent (although fancier) way of stating this observation is: in both versions the information is structured hierarchically, but the lexical representation is different, i.e., same information structure, different lexical representation.]

4.     Observation: The two versions differ in these 3 respects:

- Implicit relationship versus explicit relationship.

- Tight coupling versus loose coupling.

- Nested (hierarchical) data versus flat data.

 

Implicit versus Explicit Relationships

 

Compare the two versions with respect to how the relationship between the Lot and Picker components are specified:

 

Version #1

 

What is the relationship between the Lot and the Picker?

 

<Lot id="1">

      <Picker id="John">

            …

      </Picker>

</Lot>

 

You might state that the relationship is:

 

      "The Lot contains the Picker"

 

Another person might state that the relationship is:

 

      "The Lot has a Picker"

 

Still another person might state that the relationship is:

 

    "The Picker is a child of Lot"

 

The relationship between the Lot and the Picker is implicit.  Let us consider the advantage and disadvantage of implicit relationships.

 

Advantage:

There is no need to create some artifact (attribute or element) to specify what the relationship is.  The syntax of XML provides a built-in relationship between an element and its children, albeit a somewhat fuzzy relationship.

 

Disadvantage:

As noted, one person may interpret the relationship in one way, another person may interpret the relationship in another way.  Thus, there is ambiguity and is subject to misinterpretation.  In any computer application, differing interpretations of things left unspecified is the most insidious of errors.

 

Version #2

 

What is the relationship between the Lot and the Picker?

 

<Lot id="1">

      …

</Lot>

<Picker id="John" locatedOn="1">

      …

</Picker>

 

Clearly the relationship is:

 

      "The Picker is locatedOn the Lot"

 

The relationship between the Lot and the Picker is explicit.  That is, the relationship (locatedOn) is explicitly specified in the instance document.  Let us consider the advantage and disadvantage of explicit relationships.

 

Advantage:

There is no ambiguity.  The relationship between the Lot and Picker components is not subject to misinterpretation.

 

Disadvantage:

There must be a common understanding between the sender and the receiver on what is being used to represent the relationship, and what its meaning is.  For example, it must be understood that the locatedOn attribute is being used to represent the relationship, and there must be a common understanding of the semantics of locatedOn.

 

Tight Coupling vs Loose Coupling

 

Compare the two versions with respect to connectedness between the Lot and Picker components:

 

Version #1

 

<Lot id="1">

      <Picker id="John">

            …

      </Picker>

</Lot>

 

The Picker is nested (buried) within the Lot.  There is tight coupling between the components.  Let us consider the advantage and disadvantage of tight coupling.

 

Advantage:

Tight coupling between components can make processing by an application easier.  For example, finding all Pickers on a Lot is easy since the Pickers are children of the Lot.

 

Disadvantage:

Tight coupling between components can make processing by an application difficult.  For example, moving the Picker from Lot 1 to Lot 2 is expensive in terms of the amount of code needed, memory needed, and processing time needed.

 

Version #2

 

<Lot id="1">

      …

</Lot>

<Picker id="John" locatedOn="1">

      …

</Picker>

 

The Lot and Picker components are physically completely separate.  The only connection between them is the pointer from the Picker to the Lot (the locatedOn attribute).  There is loose coupling between the components.  Let us consider the advantage and disadvantage of loose coupling.

 

Advantage:

Loose coupling between components can make processing by an application easier.  For example, moving the Picker from Lot 1 to Lot 2 is easy - simply change the value of locatedOn.

 

Disadvantage:

Loose coupling between components can make processing by an application difficult.  For example, locating the Pickers on a Lot is more difficult since they are separated.

 

Nested (hierarchical) Data vs Flat Data

 

Compare the two versions with respect to the physical placement of the Lot and Picker components:

 

Version #1

 

<Lot id="1">

      <Picker id="John">

            …

      </Picker>

</Lot>

 

The Picker "box" is nested within the Lot "box".   That is, the data is physically structured in a nested (hierarchical) fashion.  Let us consider the advantage and disadvantage of structuring data in a "box within a box" fashion.

 

Advantage:

Visually it is easy to see what Pickers are on a Lot.

 

Disadvantage:

The more nesting there is, the more difficult it is to understand.

 

Version #2

 

<Lot id="1">

      …

</Lot>

<Picker id="John" locatedOn="1">

      …

</Picker>

 

There are two separate "boxes".  That is, the data is physically structured in a flat fashion. Let us consider the advantage and disadvantage of structuring data in a flat/linear fashion.

 

Advantage:

Separate components are easier to understand at a glance.

 

Disadvantage:

The fact that two components are related is not immediately apparent.

 

Best Practice

 

Let’s review each of the 3 things that has been discussed in this message.

 

1.     Relationship between Components – implicit or explicit?

 

In the best of all worlds relationships between components would be explicit and built into the language.  Thus, there would be no ambiguity regarding the relationship between components, and the set of possible relationships would be known to everyone.

 

Alas, XML provides one built-in relationship and it is a fuzzy one.  So, you have two choices:

 

-        Create your own artifact (attribute or element) which specifies the relationship explicitly.

-        Use the (fuzzy) relationship that XML provides.

 

If you create your own relationship then all parties receiving your XML document must have a shared understanding of both (1) what artifact you are using to specify the relationship, and (2) the semantics of that artifact.

 

If you use the fuzzy relationship that XML provides then you risk misunderstanding.

 

Best Practice – in a mission-critical applications there can be no tolerance for misunderstanding.  Use explicit relationships.  If you are in a community where you can get shared understanding, then use explicit relationships.  If you require relationships other than parent/child then use explicit relationships.  For all other applications implicit relationships may be satisfactory.

 

2.     Coupling between Components – tight or loose?

 

Your processing requirements will strongly influence whether coupling between components should be tight or loose.  In the vineyard example we saw that loosely coupled components enabled an application to easily move a Picker to another Lot by simply changing the value of the locatedOn attribute.  On the other hand, if an application wants to list all Pickers on a Lot then nesting the Pickers within a Lot (i.e., tight coupling) makes sense.

 

Case study: consider an application that models the movement of Pickers on the vineyard.  In this example the majority of the processing is spent moving the Pickers.  Only at the conclusion of processing Picker movements is there a display of the Pickers on each Lot.  In this example, there can be no debate – loose coupling of the Picker and Lot components is essential.

 

3.     Nested (hierarchical) Data or Flat Data?

 

Nested (hierarchical) data is perhaps easier to manage, as everything is located in one tidy chuck.  On the other hand, the more nested the elements run, the more difficult it is to understand the data.

 

Conversely, flat data is perhaps less easy to manage, as the components are scattered about.  On the other hand, components in isolation are typically easier to understand.
XML Editor - Download a 15 Day Free Trial Now >
See What's New in Stylus Studio >
Buy Stylus Studio - XML Editor - Now >
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member