Henry Story wrote:
> What you mean to say is "elegance at the cost of functionality
> provides no gain".
No. I meant it when I said that "Elegance at the cost of truth
provides no gain." The problem you see is that I am a Platonist when it
comes to software design and always have been. "The Cave" is, I think, the
essential metaphor for good software design and systems architecture. Old
DEC folk will remember my constant ranting about "The Separation of Form and
Function" which later lead to the three tier architecture that is so common
today...
I've often seen people make the mistake of choosing what is
"functional" over what is "true." The result is almost always some "bad" and
unanticipated side-effect that eventually bites you in a very unpleasant
way.
> I think that when you come to the conclusion that you have an idea
> that a widely deployed modelling tool cannot express then you should
> be suspicious about your idea.
Sure, I'm suspicious. However, I'm also aware that even the authors
of UML make it clear that while UML is very broadly useful, it is not the
answer to all modeling problems. UML is a compromise between three or four
different views of the modeling problem and there is much that it can't
express. Normally, its expressive limitations aren't a problem -- but not
always.
I see an abstract entry as having two parts:
1) Context -- provided by <head/> and
2) Content -- provided by the non-head elements of atom:entry.
I view "Feeds" as streams of entries and explain away the various
syntactical oddities as markup-minimization and reuse of <head/> via
inheritance. An entry is simply a feed which provides only one "content"
element (which we call an "entry"). A compound feed is a stream of entries
in which it is not always possible or not correct to attempt to "reuse" the
context provided by a single <head/> element. That is why each non-original
entry in a compound feed should provide its own <head/>. Thus, you can look
at a compound feed as a "Feed of Feeds" where each contained feed only
provides one "content". (But, remember that we've explicitly decided not to
support "Feed of Feeds" in the concrete syntax even though it is clear that
such a thing is reasonable in an abstract sense. In fact, any compound feed
that contains two or more entries from the same source feed could be more
efficiently modeled as a Feed of Feeds -- if we hadn't decided to prohibit
that in order to make things simpler for implementers by preventing infinite
nesting of feeds.)
The above paragraph should give you some idea of why the modeling
tools will be challenged here... While we can design clean, abstract and
elegant models, what we've done throughout the Atom discussion is make
various compromises (like minimization, inheritance, arbitrary nesting
constraints, etc.) that address the needs of implementers -- not modelers.
Remember, we're dealing with bits-on-the-wire here -- not API's or
abstract models. There is a mapping that must be done between the
bits-on-the-wire and the models. You can't expect the two to be identical.
You can only ask that the mapping function be of finite complexity.
bob wyman
