[XML-DEV Mailing List Archive Home]
[By Thread]
[By Date]
[Recent Entries]
[Reply To This Message]
{Spam?} Re: 3 XML Design Principles
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.
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
|
|
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
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.
|
|