[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PaceEntriesAllTheWayDown

I wonder if it would help with some of these questions to think of a Feed as an Entry. This is something I had explored a while ago, but then given up on to come to a model like the one just presented by Robert Sayre.

The model Robert has is to have an Feed simply be a list of Entries, with one head Entry given a special position, and a special meaning

<Feed>
   <headentry>
     <author>Henry Story</author>
     ...
   </headentry>
   <entry>...</entry>
   <entry>...</entry>
   <entry>...</entry>
</Feed>

As a class diagram one could present this like this

JPEG image


IE. The feed has a head Entry and a number of pointers to the Entry constructs. Here the Feed is a very small construct. Notice that there is something a little odd in this model, which is that the origin property points to an Entry, and not to the Feed, as I think some people had intended it to. But this may not be a very big problem either.

Another way of modeling this is the to think of a Feed as being a subclass of an Entry, thereby inheriting all its properties, but with a few extra properties perhaps, such as a tagline.

In xml this would be written more like this perhaps:

<Feed>
   <author>Henry Story</author>
     ...
   <entry>...</entry>
   <entry>...</entry>
   <entry>...</entry>
</Feed>

ie we loose the <head> or <headentry> tags completely, and are back to the older syntax. This can be represented in familiar UML like so:

JPEG image



Now the origin property is pointing to a Feed. Notice that the Feed is an Entry, so it is also really pointing to an Entry.

To be able to choose between these two models it may again be useful to move on to the Atom API. It might for example be very advantageous to think of a Feed as an Entry, that can be edited just like another Entry. Publishing an Entry may just be to add the Entry to a well known and accessible Feed. This is one way how I see the Atom API being helping us clean up some final syntax decisions.

Henry Story
http://bblfish.net/blog/


On 9 Nov 2004, at 10:22, Eric Scheid wrote:


On 9/11/04 4:27 PM, "Antone Roundy" <antone@xxxxxxxxxxxxxx> wrote:

2) Does atom:entry get an atom:version? how does it make sense to put
atom:introspection into atom:entry vs. atom:headentry? same question
for atom:post? does atom:headentry get an atom:edit? if so, can it be
used to edit the atom:tagline, even though that's not in
atom:headentry? if not, how is atom:tagline going to be edited? ...and
so on.


are the atom:introspections in each of the atom:entry meant to have the same
value? what does it mean if the third entry has a different value from the
second entry? repeat for each of the atom:head children being moved into
atom:entry.

e.