RE: [xml-dev] 3 XML Design Principles

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>

The relationship between the Lot and the Picker is implicit.  Implicit relationships are bad because one person may interpret the relationship in one way, another person may interpret the relationship in another way.
AND

Implicit relationships are bad.  They are subject to misinterpretation.

Explicit relationships are good.  They are not subject to misinterpretation.
</Quote>

 

I would say that this is an insufficiently supported generalization, as it depends on requirements, and the "known reach" of the data (that is, are all trading partners known contractually, or can there be unknown, non-contractually-known trading partners). That is, if one has 2 in-house applications and one produces the first Version #1 XML document shown below, and the other consumes it, the consumer will know probably what the relationship means perhaps because of its known mapping of the XML document to its relational schema (i.e. it will already know how to create the necessary joins). The same may be said if the producer and consumer are among two trading partners, if they are "contractually aware" of each other.

 

However, in cases in which there is no contractual awareness, then the strong possibility that there will be misinterpretation is absolutely an issue.

 

Bottom line: Depends on the situation.

 

On "Tight Coupling vs Loose Coupling:"

 

Keep in mind here that, if this is a data exchange scenario, we're talking about the syntactical representation of the information on the wire, which may very well be different than the manner in which the information is ultimately persisted in a receiving system (unless, of course, the XML document is persisted as-is in a native XML database). So we should be careful not to mix the notion of tight/loose coupling for the wire representation with the ultimate persisted representation, which may have different processing consequences.

 

On "Flat data is good data!":

 

Don't buy it for even a second, as stated. We're making sweeping generalizations here without even remotely considering context, and the inherent flexibility of XML. I believe this defies the very principles on which XML was built.

 

Kind Regards,

Joseph Chiusano

Booz Allen Hamilton

Strategy and Technology Consultants to the World

 

---

From: Roger L. Costello [mailto:costello@mitre.org]
Sent: Saturday, January 29, 2005 12:20 PM
To: 'XML Developers List'
Subject: [xml-dev] 3 XML Design Principles

Hi Folks,

Below I propose a few XML design principles.  I am interested in hearing your thoughts on them, i.e., do you agree or disagree with them?

Which is Better Design?

Suppose that I have data about a grape vineyard.  Below I show two lots on the vineyard, and a picker on one of the lots.  I show two ways of designing the data.  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>

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

The above two versions both have two components:

1. A Lot component
2. A Picker component

Both versions are modular, i.e., both represent the Picker located on Lot 1.

However, the two versions differ in three respects:

- Implicit relationship versus explicit relationship.
- Tight coupling versus loose coupling.
- Nest (hierarchical) versus flat data.

Implicit versus Explicit Relationships

Version #1

What is the relationship between the Lot and the Picker?

<Lot id="1">
      <Picker id="John">
            <metabolism>2</metabolism>
            <grape-wealth>20</grape-wealth>
      </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"

The relationship between the Lot and the Picker is implicit.  Implicit relationships are bad because one person may interpret the relationship in one way, another person may interpret the relationship in another way.

Version #2

What is the relationship between the Lot and the Picker?

<Lot id="1">
      <ripe-grapes>4</ripe-grapes>
</Lot>
<Picker id="John" locatedOn="1">
      <metabolism>2</metabolism>
      <grape-wealth>20</grape-wealth>
</Picker>

Clearly the relationship is:

      "The Picker is locatedOn the Lot"

The relationship (locatedOn) is explicitly specified in the instance document!

XML Design Principle #1

Implicit relationships are bad.  They are subject to misinterpretation.

Explicit relationships are good.  They are not subject to misinterpretation.

Tight Coupling vs Loose Coupling

Compare the two versions with respect to how loosely connected the Lot and Picker components are:

Version #1

<Lot id="1">
      <Picker id="John">
            <metabolism>2</metabolism>
            <grape-wealth>20</grape-wealth>
      </Picker>
</Lot>

The Picker is nested (buried) within the Lot ... Tight coupling!

Version #2

<Lot id="1">
      <ripe-grapes>4</ripe-grapes>
</Lot>
<Picker id="John" locatedOn="1">
      <metabolism>2</metabolism>
      <grape-wealth>20</grape-wealth>
</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) ... Loose coupling!

XML Design Principle #2

Tight coupling is bad.  It makes processing difficult.

Example: moving the Picker from Lot 1 to Lot 2 in the tightly coupled version is difficult in terms of the amount of code needed, memory needed, and processing time needed.

Loose coupling is good.  It makes processing easy.

Example: moving the Picker from Lot 1 to Lot 2 in the loosely coupled version is easy - just change the value of locatedOn.

Nested (hierarchical) vs Flat Data

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

Version #1

<Lot id="1">
      <Picker id="John">
            <metabolism>2</metabolism>
            <grape-wealth>20</grape-wealth>
      </Picker>
</Lot>

There is a "box within a box" ... It is nested (hierarchical) data

Version #2

<Lot id="1">
      <ripe-grapes>4</ripe-grapes>
</Lot>
<Picker id="John" locatedOn="1">
      <metabolism>2</metabolism>
      <grape-wealth>20</grape-wealth>
</Picker>

There are two separate "boxes" ... It is flat data

XML Design Principle #3

Minimize the amount of nesting you use.

Nested data is tightly coupled and uses implicit relationships, both of which are bad.

Flat data is good data!

Flat data is loosely coupled and promotes the use of explicit relationships, both of which are good.

Comments?  /Roger