[
Lists Home |
Date Index |
Thread Index
]
hi roger,
i guess i cheat when doing this. the more i think about these things,
the more i'm convinced the right thing to do is to poke the data into a
proper relational database so you can pull it out any way you want easily.
allowing that i have my own semantic database technology :) the solution
for my company is to import / export rdf as the front end and
hierarchical structures in xml (export only at this stage).
associative structures is something i can't quite figure in xml yet - so
i go back to the rdb where it's very easy.
so if you want to really confuse yourself (like i'm doing at the moment)
let's assume xml is just a storage technology. and then perhaps the most
importnat things to come out of xml are the extras - xpath, xquery, xsl,
rdf - and if we apply them to a traditional data store, all sorts of
wonderful things happen and problems like the one below have a wide
range of solutions.
rick
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
>
> !DSPAM:41fbc6af94781510613120!
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
