Re: [xml-dev] The markup minimalist

interesting points,

data modelling is fundamentally hard through space and time (and different hands/concerns).

I think many of Roger's 'rules' could be sensible when applied in the 'one true' data model scenario where a cautious approach can be useful, though any incremental development usually means amend of the original data model or code ... having an underpowered data model adds magnitude of effort in the code. So where do you put the technical debt ?

I've found having an 'onion skin' approach to data modelling using derived schema that perfectly service each layer (with no knowledge required of layers underneath) one way to distribute maintenance costs and get the right balance of flexibility. Conversely, putting in such abstractions up front tend to complicate grokking of said data model in its simplest instance ... oh well,those days I daydream about what a schema language, for XML, could have looked like, then move on.

Attempting to 'get it right' for all concerns is where my data models fail as I can't see enough 'moves ahead' to predict what will be required in the future, so I try to be cautious, but more importantly I try to make the data model fit for single purpose.

Jim Fuller

On Mon, Nov 3, 2014 at 4:46 AM, Rick Jelliffe <rjelliffe@allette.com.au> wrote:

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