Re: The markup minimalist

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

On 02/11/2014 1:32 AM, "Costello, Roger L." <costello@mitre.org> wrote:

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