[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Flatter is Better (part two)

• From: =?UTF-8?B?UGlvdHIgQmHFhHNraQ==?= <bansp@o2.pl>
• To: xml-dev@lists.xml.org
• Date: Wed, 03 Dec 2014 11:39:33 +0100

Hi Roger,

On 03/12/14 11:28, Costello, Roger L. wrote:

Hi Peter,

You wrote that an XML design must take into consideration a-priori
knowledge about the environment that the design must live within:

Ø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

How does one design XML in the absence of such a-priori knowledge?

That is, how does one design XML that can be used over lots of different
networks with lots of different bandwidths? How does one design XML that
can be used by lots of different consumers (applications) with widely
varying processing needs?

I thought that the whole point of designing XML is to avoid tying a
design to a specific network, a specific application, a specific use-case?

I thought that the whole point of designing XML is to create a design
that is usable across lots of different networks, by lots of different
applications, by lots of different use-cases?

I thought that the whole point is to free XML of such tethering.

XML, run free!

In the absence of a-priori knowledge we must, I contend, strip away all
preconceived notions of “the right XML hierarchy.” I content that’s what
a flat design provides: it provides a series of components that that can
be mashed up with other components, can be transformed (parsed) into any
hierarchy, and can be normalized/stripped-down. The flat design, it
seems to me, represents the ultimate goal of XML – freedom from a-priori
constraints/knowledge!

                 XML design, be eternal!

Comments?

/Roger

*From:*Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
*Sent:* Tuesday, December 02, 2014 10:51 AM
*To:* Costello, Roger L.; xml-dev@lists.xml.org
*Subject:* Re:  Flatter is Better (part two)

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
<mailto: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>
    <cityname="Davenport">
    <streetname="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>
    <cityname="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

• References:
  • Flatter is Better (part two)
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: Flatter is Better (part two)
    • From: Peter Hunsberger <peter.hunsberger@gmail.com>
  • RE: Flatter is Better (part two)
    • From: "Costello, Roger L." <costello@mitre.org>