OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Better design: "flatter is better" or "nesting is bette

[ Lists Home | Date Index | Thread Index ]
  • To: "Costello, Roger L." <costello@mitre.org>, "XML Developers List" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Better design: "flatter is better" or "nesting is better" ?
  • From: "Chiusano Joseph" <chiusano_joseph@bah.com>
  • Date: Fri, 30 Sep 2005 14:40:15 -0400
  • Thread-index: AcXF5F4j+YX7TW5aSCua5q2ryNPJpAACalwA
  • Thread-topic: [xml-dev] Better design: "flatter is better" or "nesting is better" ?

</Quote>
Part 2: Design your XML to be flat, with direct mappings from XML to (relational) database tables.
</Quote>
 
Sometimes one is also using XML without any notion of a specific database type or database design - for example, for a data exchange in which XML is used as an intermediary exchange format to bridge between XML vocabularies. In such cases, all one knows is the "source" vocabulary and the "target" vocabulary, not any storage mechanism on either end. So in that case, it's a choice involving other factors (such as design preference).
 
Joe
 
Joseph Chiusano
Booz Allen Hamilton
 
700 13th St. NW
Washington, DC 20005
O: 202-508-6514 <= new office number as of 09/19/05
C: 202-251-0731
Visit us online@ http://www.boozallen.com
 


From: Costello, Roger L. [mailto:costello@mitre.org]
Sent: Friday, September 30, 2005 1:28 PM
To: XML Developers List
Subject: RE: [xml-dev] Better design: "flatter is better" or "nesting is better" ?

Hi Folks,
 
Many thanks for your excellent comments! 
 
First, I will attempt to summarize the points that were raised in your comments.  Then, in the spirit of the philosopher Karl Popper I will boldly propose a solution to the question: "How should XML documents be designed?"
 
Points Raised in your Comments:
 
(1) "Design for today's applications.  The future is unknown."
 
      Implication: let your applications dictate how your XML is designed.
 
(2) When designing your XML, ask if your applications:
 
        - operate directly on the data in an XML document, or
        - on the data after being loaded in a (relational) database?
 
(3) If the data is not in a form that is well-suited to processing by your applications then change the form of the data.  From point (2) we must consider two cases when dealing with changing the form of data:
 
     Case 1: Applications operate directly on the data in an XML document
 
           Implication: write an XSLT stylesheet to transform the (XML) data into a form that is well-suited to processing by applications.
 
     Case 2: Applications operate on the data after the data has been placed into a (relational) database
 
           Implication: modify the database (tables, primary keys, foreign keys, etc)
 
Cost of changing the form of data: Is it cheaper to change a stylesheet or a (relational) database?
 
(4) "What application uses *that* markup? If there isn't one that *needs* it, today, then get rid of it."
 
         Implication: keep your XML design simple, free of nonessential tags.
   
[Tangential Remark: There is a philosopher by the name of Karl Popper.  One of the things that he is well-known for is his idea that a key characteristic of science is that all its hypotheses are testable, and science progresses most quickly when a hypothesis is submitted to a large audience, who then scrutinizes (tests) it.  Thus, in the spirit of Karl Popper I propose the following hypothesis.]
 
Hypothesis - How to Design XML Documents
 
I am supremely compelled by the argument that the future is much too uncertain to bother attempting to anticipate or design for.  Thus I put this down as the first part of this hypothesis:
 
    Part 1: Design your XML documents so that they are well-suited for processing by your applications *today*.
 
In other words, how your data is going to be processed tells you how to design your XML.
 
A large percentage (majority?) of applications today operate on the data only after it is placed into a (relational) database.  A smaller percentage (minority?) of applications operate directly on the data in an XML document.  So, as an 80-20 rule I make the second part of this hypothesis:
 
    Part 2: Design your XML to be flat, with direct mappings from XML to (relational) database tables.
 
I am also supremely compelled by the argument to keep the markup (tags) to a minimum.  So here's the third part of this hypothesis:
 
    Part 3: Eliminate nonessential markup (tags).  Only use tags that are actually used by your applications *today*.
 
To recap - when designing XML:
                         - be practical;
                         - be simple;
                         - don't use unnecessary tags;
                         - design your XML to work well with your applications *today*;
                         - most likely, "flatter is better".
 
Comments?  /Roger
 
 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS