[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: 3 XML Design Principles


xml design principles
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@z...
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.