XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
XML data interchange format: Flatter is better

Hi Folks,

Designing data interchange formats can be quick, easy, and inexpensive. 

The comments made in this message are intended for this environment:

	The XML is distributed to a broad spectrum of consumers, 
	each consumer might perform widely different operations 
	on the XML.

I recommend making flat XML. Design your XML to just have a root element, containing a linear sequence of elements. 

Be a markup minimalist.

Here are the reasons for my recommendation: 

1. Consumers of flat XML can apply powerful parsing techniques to the linear sequence of elements. Thus, consumers can add whatever structure is appropriate for their particular applications to process the data efficiently.

2. XML Schema design and implementation of flat XML is trivial: simply create an XML Schema with a sequential list of element declarations. 

3. If, on the other hand, you were to design the XML to have lots of structure, it is a near certainty that the structure will not be suitable for many of your consumer's applications. Further, its structure is likely to hamper powerful parsing techniques.

The "flatter is better" philosophy may be summarized this way: 

	I can't predict how my consumers will want the data structured, 
	so I won't try to predict. I will let them apply their own structure 
	to the data.

Let's take an example. Suppose that you want to model a grape vineyard, with pickers scattered about on the various lots. The following XML is not flat. It's probably a design that most people would come up with. I assert it is a bad design.

<Vineyard>
    <Lot id="1">
        <ripe-grapes>4</ripe-grapes>
        <Picker id="John">
            <metabolism>2</metabolism>
            <grape-wealth>20</grape-wealth>
        </Picker>
    </Lot>
    <Lot id="2">
        <ripe-grapes>3</ripe-grapes>
    </Lot>
    ...
</Vineyard>

That design is well-suited to operations such as this:

	What Pickers are on lot 23?

But it is horrible for operations such as this:

	Move Picker John to Lot 2.

Don't design XML that way. Design XML to be flat, like this:

<Vineyard>
    <lot-number>1</lot-number>
    <ripe-grapes>4</ripe-grapes>
    <picker>John</picker>
    <metabolism>2</metabolism>
    <grape-wealth>20</grape-wealth>
    <lot-number>1</lot-number>
    <ripe-grapes>3</ripe-grapes>
    ...
</Vineyard>

That's a beautiful design. It enables powerful parsing techniques to be applied to it. For instance, one consumer may parse it to generate the above structuring. Another consumer may parse it to generate this radically different structuring:

<Lot id="1">
      <ripe-grapes>4</ripe-grapes>
</Lot>
<Lot id="2">
      <ripe-grapes>3</ripe-grapes>
</Lot>
<Picker id="John" locatedOn="1">
      <metabolism>2</metabolism>
      <grape-wealth>20</grape-wealth>
</Picker>
...

And another consumer may parse it to generate still another structuring.

Each consumer parses the flat XML to create a structuring that is well-suited to their particular application processing.

Are you creating XML "for the long haul"? 

Are you creating XML "for a broad, diverse set of clients"? 

Are you a manager and don't want to dump a lot of time and money into creating "the perfect XML Schema design"?

Then create flat XML. 

Flatter is better!

For more info on parsing flat XML see my recent posts:

Recursive Descent Parsing for XML Developers: http://lists.xml.org/archives/xml-dev/201410/msg00017.html

Bottom-up Parsing for XML Developers: http://lists.xml.org/archives/xml-dev/201409/msg00016.html

Comments welcome.

/Roger



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS