{Spam?} Re: 3 XML Design Principles

["Dimitre Novatchev" <dnovatchev@yahoo.com>]

The answer largely depends on the data being modelled and the generality of the representation. The "has a" relationship is probably not too specific and thus contributed to your question.

 

However a "has private members" relationship is definitely better presented in a hierarchical way. For example:

 

  <date>

      <day>30</day>

      <month>1</month>

      <year>2005</year>

  </date>

 

There is analogy to this in programming languages -- members of a class may be private or public and a private class may be defined inline (nested) to be used solely by the encompassing class.

 

Whenever the data to be represented is not hierarchical (no single root, repeating subtrees, loop structures), then it becomes necessary to realise that an arc is an object in itself and has to be represented separately. A good example is the XGMML (eXtensible Graph Markup and Modeling Language):

 

   http://www.cs.rpi.edu/~puninj/XGMML/

 

 

Dimitre Novatchev.

 

 

 

 

 

"Roger L. Costello" <costello@mitre.org> wrote in message 200501291720.j0THK3517843@smtp-bedford.mitre.org">news:200501291720.j0THK3517843@smtp-bedford.mitre.org...

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