[
Lists Home |
Date Index |
Thread Index
]
On Sat, Jan 29, 2005 at 12:19:57PM -0500, Roger L. Costello wrote:
> Below I propose a few XML design principles. I am interested in hearing
> your thoughts on them, i.e., do you agree or disagree with them?
I think they are not very universal.
> Which is Better Design?
Good design takes a lot of factors into account, not just one or two.
> XML Design Principle #1
> Implicit relationships are bad. They are subject to misinterpretation.
You can't get away from implicit relationships (e.g. "in the same
document as", "followed by", "contains the same number of vowels as").
The answer isn't to avoid them but rather to document them.
> Tight Coupling vs Loose Coupling
The idea you have that nesting is a tighter coupling than sequence seems
to me very arbitrary. If you replace nesting with an id/idref pair,
you now have a pointer that needs to be maintained whenever you
transform the document. It's not clear which is the more fragile.
> Minimize the amount of nesting you use.
This one could be better written as
Use an appropriate amount of nesting.
Usually when I introduce people to using XML I suggest that it's useful
to group similar items inside an element:
<list-item level="1">point 1</list-item>
<list-item level="2">point 2.1</list-item>
<list-item level="2">point 2.2</list-item>
is much harder to process with XSLT or with a native XML style system
than something like
<bullet-list>
<item>point 1</item>
<bullet-list>
<item>2.1</item>
<item>2.2</item>
</bullet-list>
</bullet-list>
If I hand you the text of War and Peace, you'll generally want the
paragraphs nested inside chapter elements, each with a title element.
You're unlikely to want a "table of contents" element containing chapter
titles, and each paragraph having a chapter-number attribute, with no
chapter element and no per-chapter title. Yes, you could stitch the
document back together, but you'll almost _always_ need to do so,
Similarly, within a paragraph of text, you're <emph>very</emph> likely
to want phrase-level markup, and you're not likely to want to take
that out-of-line and use references -- the text becomes too hard to edit
for one thing, in almost all the XML editors I've used.
> Nested data is tightly coupled and uses implicit relationships, both of
> which are bad.
>
> Flat data is good data!
The real world is bad! Let's simplify and stop modeling it! Let's not
do anything hard!
Or to put it another way, less cynically ;-),
(1) nested data is tightly coupled
I don't accept that you've demonstrated this when compared to data
connected by a pointer.
(2) Nested data uses implicit relationships
Actually the "is nested within" relationship is explicit.
What you're doing is inferring extra relationships that your
sample markup did not, strictly speaking, license you to infer.
(3) both (1) and (2) are bad
I don't believe you've shown this at all.
(4) flat data is good data
A conclusion based on an incorrect premise is, in formal logic
terms, meaningless. However, if you find your nested data is
being naughty, I advise caution before spanking it, as the
pointy brackets are sharp.
Or to put it another way, there's a place for flat data and a
place for structured data.
Best,
Liam
--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
|
