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

["Costello, Roger L." <costello@mitre.org>]

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