RE: [xml-dev] 3 XML Design Principles - a rebuttal

["Chiusano Joseph" <chiusano_joseph@bah.com>]

+1

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 

> -----Original Message-----
> From: Frank Manola [mailto:fmanola@acm.org] 
> Sent: Sunday, January 30, 2005 5:15 PM
> To: Roger L. Costello
> Cc: 'XML Developers List'
> Subject: Re: [xml-dev] 3 XML Design Principles - a rebuttal
> 
> 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
> 
> -----------------------------------------------------------------
> 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>
> 
>