You need to establish your scenario first.
* If you want to leave the responsibility for ordering and grouping and traversing data to the developer, then arrangements closer to 3NF may be appropriate.
* If you have a target algorithm or expected existing system, then arranging your data to fit them may be best. Ignore the sneers of abstract modelers.
* If you have a strong idea of the usual patterns of access (e.g. documents), then rich hierarchical markup may be best: some nosql systems do this.
* If you dont want to penalize any application or developer, then you are in the scenario-free world of voodoo pronouncements. You think you are free, but you will just be ruled by slogans and know-alls and informed guesses.
I expect a viable data format needs to be at least good for something, at least one thing, rather than designed to be good for nothing.
But a caution about flatness: when people have a flat format but need structure, they lower the structure into names: you get long structured names and ids with many segments and dots and minus: out of reach of most validation. Data has structure, and we can decide whether it is appropriate to expose or bury that structure.
cheers
Rick
The Markup Minimalist Credo
1. Flatter is better. Add structure (markup) to XML only when absolutely necessary.
2. Data exchange formats: make them flat.
3. When sending data to consumers, distribute the data in a flat format.
4. When consumers receive the flat XML they may add structure (markup) to facilitate simpler and more efficient Schematron assertions and/or simpler and more efficient application processing. Different consumers will add different structure (markup), depending on their (local) requirements.
Comments?
/Roger