Re: [xml-dev] Flatter is Better (part two)

[Peter Hunsberger <peter.hunsberger@gmail.com>]

Roger,

I really think you need to give up on this particular line of reasoning.  In particular, your examples make it clear you're aiming this at data exchange, not documents. As such, there is no "better" as far as flat or fat.  Better is determined by the needs of the data exchange partners and can vary by use case, network bandwidth, target device and a host of other constraints that do not allow for the kind of generalizations that you are trying to make.  Rather, at best these recommendations are useless and at best they will lead to broken designs that do not fit any needs at all.

If you want to make a generic statement about XML formatting it should be along the lines of:

"There are many technologies for transforming XML to fit the needs of the business partners exchanging the XML.  When designing a system to exchange XML data, design your systems to exploit these technologies in order that the data exchange meet the needs of the business partners in the best possible way."

On Tue Dec 02 2014 at 4:31:27 AM Costello, Roger L. <costello@mitre.org> wrote:

Hi Folks,

 

The flat design is about creating XML documents that consist of a long series of standalone components:

 

 

A component in the document can be combined with other data (mashup):

 

Let’s take a concrete example to compare the flat design versus the fat design.

 

Here is a flat design:

 

<Iowa>
    <house>
        <street>1009 Arlington Court</street>
        <city>Davenport</city>
        <style>Ranch</style>
        <porch>open</porch>
        <year-built>1951</year-built>
        <square-feet>1700</square-feet>
    </house>
    <house>
        <street>1008 Arlington Court</street>
        <city>Davenport</city>
        <style>Ranch</style>
        <porch>closed</porch>
        <year-built>1955</year-built>
        <square-feet>1850</square-feet>
    </house>
    ...
</Iowa>

 

The document consists of a long series of standalone <house> components. Any of those <house> components could be mashed-up with other data, e.g., mashup a <house> component with a <GPS> component.

 

Here is a fat design:

 

<Iowa>
    <city name="Davenport">
        <street name="Arlington Court">
            <house>

               <street-number>1009</style>
                <style>Ranch</style>
                <porch>open</porch>
                <year-built>1951</year-built>
                <square-feet>1700</square-feet>
            </house>
            <house>

                <street-number>1008</style>
                <style>Ranch</style>
                <porch>closed</porch>
                <year-built>1955</year-built>
                <square-feet>1850</square-feet>
            </house>
        </street>
        ...
    </city>
    <city name="Cedar Rapids"> ... </city>
    ...
</Iowa>

 

The flat design and the fat design are radically different!

 

In the fat design the houses have been grouped into streets and the streets have been grouped into cities. The street name data has been removed from each <house> and also the city name data has been removed from each <house>. Consequently, each <house> is no longer a standalone component. House data is now fragmented, scattered over the document. The ability to do mashups has been lost (or, at least, greatly hampered). The fat design has normalized the data and, as I argued in my last message: Normalization is horrible for data exchange formats.

 

It’s best to exchange the data in the flat design. Consumers can transform it into the fat design, if needed.

 

Recommendation: When designing a data exchange format create a flat design.

 

Comments?

 

/Roger