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

Re: 3 XML Design Principles - a rebuttal

• To: "Roger L. Costello" <costello@m...>
• Subject: Re: 3 XML Design Principles - a rebuttal
• From: Frank Manola <fmanola@a...>
• Date: Sun, 30 Jan 2005 17:14:43 -0500
• Cc: 'XML Developers List' <xml-dev@l...>
• In-reply-to: <200501302007.j0UK7C514562@s...>
• References: <200501302007.j0UK7C514562@s...>
• User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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

• References:
  • RE: 3 XML Design Principles - a rebuttal
    • From: "Roger L. Costello" <costello@m...>

• Prev by Date: RE: Even if you're not ... was If you're going to the W 3C meeting in March
• Next by Date: RE: 3 XML Design Principles - a rebuttal
• Previous by thread: RE: 3 XML Design Principles - a rebuttal
• Next by thread: Re: 3 XML Design Principles
• Index(es):
  • Date
  • Thread