[
Lists Home |
Date Index |
Thread Index
]
First let me say you must have the coolest job :)
But you are totally ignoring a way to reference some unique 'thing.' You
can define something once and reference it. So I would say nesting is
good but define references to things that can go more than one place.
best,
-Rob
Roger L. Costello wrote:
> 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
>
|
