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: "XML Developers List" <xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Better design: "flatter is better" or "nesting is better" ?
  • From: "Costello, Roger L." <costello@mitre.org>
  • Date: Fri, 30 Sep 2005 13:28:27 -0400
  • Thread-index: AcXF5F4j+YX7TW5aSCua5q2ryNPJpA==
  • Thread-topic: 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