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?
With a clear model, clear serialization, and clear documentation, for
the interested parties to understand and implement if they decide they
need it?
> 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 wonder what you mean by "designing XML". You just suddenly sit down
and design XML, for the wide world to use?
Best,
Piotr
> 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:]
> *Sent:* Tuesday, December 02, 2014 10:51 AM
> *To:* Costello, Roger L.;
> *Subject:* Re: [xml-dev] 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. <
> <mailto:>> 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
>
