Subject: PaceEntriesAllTheWayDown

From: Antone Roundy <[email-masked]>
Date: Mon, 8 Nov 2004 22:27:57 -0700

Questions and comments:

1) Why does atom:tagline go outside of atom:headentry? Why does 
atom:generator go inside atom:headentry?

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.  There seem to be lots of differences between the contents of 
atom:head (or atom:headentry) and atom:entry. With only section 4.2.11 
being removed, how does this substantially shorten the spec?

3) Could you elaborate on "Allows a straightforward way to implement 
hierarchy". I think I sort of get it, but this feels like a much bigger 
shift than the sparse language of the Pace would imply.

4) atom:headentry? he a dentry? what does this have to do with teeth?  
;-)  Seriously though, why not stick with the name atom:head, even if 
it is to be some sort of Entry Construct?

---

From: Eric Scheid <[email-masked]>
Date: Tue, 09 Nov 2004 20:22:52 +1100

On 9/11/04 4:27 PM, "Antone Roundy" <[email-masked]> wrote:

> 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.

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 11:59:55 +0100

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

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:

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/

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 07:40:20 -0500

> atom:generator go inside atom:headentry?

People seem to want to move atom:tagline. atom:generator is allowed in 
atom:entry, it's just required in atom:headentry.

> 2) Does atom:entry get an atom:version? 

No, that stays on the feed, though YAGNI.

> how does it make sense to put 
> atom:introspection into atom:entry vs. atom:headentry? same question for 
> atom:post? 

What doesn't make sense? same question for atom:post.

> does atom:headentry get an atom:edit? 

It could, but that's optional.

> 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.  

Maybe the tagline is not editable. It currently isn't.

> There seem 
> to be lots of differences between the contents of atom:head (or 
> atom:headentry) and atom:entry. With only section 4.2.11 being removed, 
> how does this substantially shorten the spec?

I should have included a section that says to remove all of section 4. 
Whoops.

> shift than the sparse language of the Pace would imply.

Well, it makes it possible to have every entry become a feed/collection, 
a very common request (often seen on lj_dev, for example). It's kind of 
a big shift I guess, but like Graham said, 90% of the elements were the 
same.

> ;-)  Seriously though, why not stick with the name atom:head, even if it 
> is to be some sort of Entry Construct?
> 

Sure, I just couldn't think of a decent name.

Robert Sayre