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]
Re: [xml-dev] Flatter is Better (part two)

On 12/2/2014 8:50 AM, Peter Hunsberger wrote:
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.
+1. The thing is, you always have to ask "better? better for *what purpose*?" In your zeal to promote what you see as "simple", you have been consistently overlooking the purpose. And purposes vary.

Example: Microsoft Word binary files used to be (so I have read) essentially the memory image of the data. Word could read the bytes directly from the disk file into memory. That's why they loaded so quickly, even in computers that were very slow in modern terms.

Isn't that the ultimate in efficiency and compactness? Yes, if you were only using Microsoft Word. Yes, if you had to read the files off a slow floppy disk, or over a slow network. No, if you wanted to be able to use Word files with many different programs.

Also, normalizing data isn't really about "flattening" vs. "fattening". It's about getting the dependencies identified clearly, and removing redundancies. Depending on how you generate your interchange document, when you have redundant data you may end up with inconsistencies, especially after several rounds of revisions and extensions to the code. What is the recipient supposed to do in the face of inconsistent data?

I think that everyone would agree that simplicity goes along with less structure. I value simplicity. But, as has been attributed to Einstein, "as simple as possible but no simpler".

Tom Passin

[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