Henry Story wrote:
> 2. A Feed is a Entry ...
> I think you would probably really like this model...
No. I don't like it at all.
Please note that I've been arguing for PaceHeadInEntry. It should be
obvious that I think that: "An Entry is a Feed." I do not think that "A Feed
is an Entry".
If PaceHeadInEntry is accepted, entry is most appropriately seen as
a restricted subclass of Feed -- with the restriction being that an entry
can contain no entries. An entry is simply a single entry feed and we do
some markup minimization that allows us to remove the "entry" wrapper tag
around the entry specific elements. Unfortunately, I think UML can't express
this.
Saying that "A Feed is an Entry" may result in simpler UML, shorter
documents, etc. However, I think that such simplifications should not be
pursued if the cost is a loss of accuracy in the model. Elegance at the cost
of truth provides no gain.
If PaceHeadInEntry is accepted, then conceptually, an Entry looks
like this:
<entry>
<head></head>
<entry>
.. elements of entry ...
</entry>
</entry>
However, given that the inner instance of the entry tag provides no
utility, we have chosen to save a few bytes and encode an entry as:
<entry>
<head></head>
.. elements of entry ...
</entry>
This model supports what I've often suggested when I say that I
think that a feed is simply a sliding-window on a stream of events. An Entry
is simply a feed with a window-size of 1. This is an important observation
if you're in the composite or aggregate feed business -- like I am. What we
require is an atomic unit that can be moved about without information loss.
I also believe that the inheritance of and from <head/> is much more
intuitive if you view an entry as a single entry feed.
Entries are single entry feeds. Feeds are not entries -- they are
merely streams or collections of entries.
bob wyman
