[
Lists Home |
Date Index |
Thread Index
]
Roger--
This is getting there, but it seems to me there's a basic idea that
needs to be more explicit, and catered to, in much of your exposition.
It's embedded in some of your examples, and several of the earlier
respondents have mentioned it using different words. The principle is
that designs (of anything) need to be evaluated with respect to
satisfying an identified set of requirements. Designs don't exist in a
vacuum. In other words, extend what you say below: "Every engineering
decision has its pros and cons", to read something like "Every
engineering decision has its pros and cons *with respect to satisfying
specific requirements*". What's the problem you're trying to solve with
a given design?
Your summary of coupling illustrates some awareness of this point, where
you note the relationship of coupling to processing requirements. On
the other hand, your summary of principle #3 refers to "ease of
management" and "ease of understanding" in a rather general way. What
kind of "management" or "understanding"? (E.g., I can think of
situations where it's the nested form that's easier to understand;
that's why so many forms use nesting, rather than small chunks with lots
of internal identifiers).
Another point that may also be worth mentioning is that often a
particular requirement can be satisfied in more than one way, and you
need to take that into account too. For example, in your initial
example you discuss explicit vs. implicit relationships. Explicit
relationships are a good idea in general, but there's often more than
one way to provide information about a relationship. In this example,
for instance, you separate pickers and lots and show the relationship
with a locatedOn attribute. But there are alternatives. For example
(considering just this one issue in isolation):
* if that's the only relationship between pickers and lots, and you
don't want to cater for later extensions to represent other
relationships, then you could have continued to use the nested
structure, and indicated (if necessary, in a machine-processable form of
some kind) the "meaning" of the relationship in a separate document of
some kind (i.e., saying in effect "pickers contained in lots are those
located there")
or
* you could have added an additional nested element, as in
<Lot id="1">
<ripe-grapes>4</ripe-grapes>
<pickersLocatedAt>
<Picker id="John">
<metabolism>2</metabolism>
<grape-wealth>20</grape-wealth>
</Picker>
</pickersLocatedAt>
</Lot>
Those alternatives may be better or worse with respect to some
requirements (or processing assumptions) you have in mind, but what are
those requirements?
--Frank
Roger L. Costello wrote:
>
> Outstanding discussion! Thanks Christian for keeping me honest.
> Every engineering decision has its pros and cons. I failed to
> consider that in my original post. So, I have completely rewritten my
> original post to (hopefully) reflect a more balanced perspective.
> Have I fairly captured the pros and cons of the 3 issues I try to
> address? /Roger
>
>
snip
|
