RE: [xml-dev] Better design: "flatter is better" or "nesting is

["Rick Jelliffe" <rjelliffe@allette.com.au>]

Hi all: first, I am back on deck again and very well, and I will start
answering email again at the new email address. Thanks again to
everyone who sent their get-well messages.

I am a little sceptical that "application" is such a general
term that (like s- words) rules-of-thumb that use that term
as if they were homogenous will wrong-foot us.

For example

> A large percentage (majority?) of applications today operate on the
> data only after it is placed into a (relational) database.  A smaller
> percentage (minority?) of applications operate directly on the data in
> an XML document.

Lumping all "applications" together, then deciding based on some
phoney quantification of what is most common that we should adopt as
a rule of thumb the rule that may suit one bunch of applications is bad
methodology.

And "percentage"? Of clients? of servers? of middleware? of messages?

Engineering is based on quantifying aspects of particular jobs in
order to be able replcate success, not lumping things together.
It is some kind of logical fallacy to apply the 80/20 rule to
collections of disparate objects.

Also, the "elimiate non-essential tags" rule flies in the
face of the capabilities of XML Schemas, where introducing extra
layers is the only way to get different content models: XML Schemas
forces you to use elements where attributes might be more natural.
Furthermore, for documents that will be sent for publising, there
is a kind of "critical mass" or minimum-density-of-metadata without
which a document is useless for publishing. It would be better
to re-phrase that "eliminate speculative tags" IMHO.

Dr Peter Sefton had a good paper on the topic of how rich to make
markup at XML Asia Pacific 2004, which is probably on the web somewhere
(I blogged it too.)

Cheers
Rick Jelliffe