[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: [Summary] Better design: "flatter is better" or "nesting

• To: 'Rick Jelliffe' <rjelliffe@a...>, 'XML Developers List' <xml-dev@l...>
• Subject: RE: [Summary] Better design: "flatter is better" or "nesting is better" ?
• From: "Bullard, Claude L (Len)" <len.bullard@i...>
• Date: Mon, 10 Oct 2005 11:25:40 -0500

And if you don't know the destination, that is a good thing
because you don't want to introduce complexity without a reason.
That is why future-proofing is mentioned: the road to hell and
good intentions.

The fact of multiple occurrence types introduces risk.  Some
schemas (eg, GJXML) attempt to mitigate this by adding extra
layers of tagging and fauxtypes to infer semantics.  How well this
actually works is a subject of some debate.   Topic maps, by
contrast, move this to a different document type or layer and
rely on locators and associations.  In my opinion, that is a
better solution because a piece of information may be used
in multiple contexts without violating a separate contract.

Once the layers are introduced into the same specification,
by reference, they will be pulled into every occurrence type
by reference in multiple contracts.  Where we can treat
those layers as hints, that can be ok.  Otherwise, we have
to converge on implementation.
 
Again, YMMV.

len

From: Rick Jelliffe [mailto:rjelliffe@a...]

Also, the more that the destination purpose or application is
unknown, the more likely it is that the (implicit or explicit)
schema will be influenced by what is easy to generate (the
originating format, if any) rather than what is easy to accept
(the destination format.)

For example, a database dump for archiving purposes is probably
going to be fairly flat (unless the database strongly has some
tree structures that the developer feels strongly enough to
bring out, or unless some automated tool plays some tricks.)

• Prev by Date: Re: funny parser
• Next by Date: Versions and profiles in RDDL
• Previous by thread: RE: how to skip parsing of a subtree?
• Next by thread: Versions and profiles in RDDL
• Index(es):
  • Date
  • Thread