[
Lists Home |
Date Index |
Thread Index
]
All,
btw point 1)c) is lost on people who still think in a relational way,
the same way that the power of inheritance is lost on them. Relational
models have caused me big problems with their impedance mismatch to
the business. More power to hierarchy and inheritance.
Oh, and just to defend myself ahead of time, yes I want my clients' XML
to look as much as possible like their idea of their business, because
it saves them time and money. The only time they need their data
normalised is at the end of a message flow, when it goes into a
database, but certainly not in XML transit.
Christian
---------------------------------
Christian Nentwich
Technical Director, Syste/\/\/ire
http://www.systemwire.com
T: +44 (0)7747 061302
---------------------------------
> Roger, all,
> I don't think these design principles are entirely fairly presented,
> since you only give the advantages of what you are advocating without
> considering the downsides, and vice versa for what you are
> discouraging. I quite like what nesting gives me, within reason, and
> here is why:
> 1) Advantages of tight coupling
> <Lot id="1">
> <Picker id="John">
> <metabolism>2</metabolism>
> <grape-wealth>20</grape-wealth>
> </Picker>
> </Lot>
> Advantages:
> a) The Picker is contained within the lot, tight coupling. I can
> immediately see which picker is associated with a lot. My support
> people can see it when the workflow explodes, and don't waste time.
> Imagine 100,000 lots with 100,000 pickers, and somebody with a text
> editor.
> b) It is easier to get the picker for a lot in XSLT. I don't need
> a key lookup, just a child navigation.
> c) If the structure was even deeper, the containment hierarchy serves
> as an abstraction. I can collapse the lot, or dig down for more
> information. Going down the hierarchy, I model from top level to details,
> e.g. in a financial trade from the overall trade down to the last
> payment.
> Yes, it is unclear whether the lot "contains" a picker or "has" a
> picker. How big is that problem? I work with pretty complex standards,
> with over 1000 schema elements, and nesting. I've never seen that
> problem expressed. If I ever see it, my child element will have a
> "role" element.
> 2) Disadvantages of loose coupling
> <Lot id="1">
> <ripe-grapes>4</ripe-grapes>
> </Lot>
> <Picker id="John" locatedOn="1">
> <metabolism>2</metabolism>
> <grape-wealth>20</grape-wealth>
> </Picker>
> a) Nothing at all ties the Picker to the Lot element. How do we know
> that the Picker is not associated with a FOO? What if there are
> elements other than lots? You need a naming convention both on
> attributes, and for ID generation or you get duplicates.
> b) A schema cannot enforce that a lot has a picker. You have to use a
> business rule or application logic.
> c) In a schema design exercise, if people use the schema to model
> their business data, they cannot visualise the relationship between
> the lot and the picker.
> Nesting wins for me! Avoid cross-referencing, unless its intention is
> to eliminate duplicate records. If you take this flat approach to its
> extreme you end up with XBRL, and then heaven help you...
> Christian
> ---------------------------------
> Christian Nentwich
> Technical Director, Syste/\/\/ire
> http://www.systemwire.com
> T: +44 (0)7747 061302
> ---------------------------------
>> 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 aremodular, 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 Lotcontains 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
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
|
