Subject: PaceEntriesAllTheWayDown

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 08:55:13 -0700

The following lists which elements can appear in atom:head and 
atom:entry according to the current draft.  I think any proposal to 
unify head and entry needs to explicitly address each of the 
differences and explain a) why there's no reason for both head and 
entry not to contain each or them, or b) why each should disappear or 
be moved elsewhere in the format, or c) why it's okay to say "head and 
entry are the same except for these differences".

Element Name		Head		Entry
============		====		=====
title			Required	Required
link				Required	Required
introspection		Yes		No
post				Yes		No[1]
edit				No[2]	Yes
author			Required	Required	(required in head or in every entry)
contributor		Yes		Yes
tagline			Yes[3]	No
id				Yes		Required
generator			Yes		No
copyright			Yes		Yes
info				Yes[4]	No
updated			Required	Required
published			No[5]	Yes
summary			No[3]	Sometimes Required
content			No		Yes
origin			No		Yes

[1] atom:post in atom:entry as a pointer to a comment feed don't seem 
unreasonable to me.

[2] atom:edit for atom:head makes sense to me.

[3] replacing atom:tagline with atom:summary sounds reasonable if not 
exactly precise in meaning.

[4] I'd say atom:info should be removed from atom:head except that part 
of the purpose of atom:head is to make the ordering rules for children 
of atom:feed simple, and perhaps even so.  I don't think I'd be too 
disappointed if atom:info just disappeared.  We could (dons asbestos 
suit) use <link rel="format-explanation" ... /> to point to an 
explanation of the feed format if we feel the need to reserve a method 
of educating view-sourcers.

[5] I guess you could conceivably have atom:published in 
atom:feed--sort of a "serving your information needs since 1894" sort 
of thing.

Other differences:
* introspection - I'm not up on what the introspection file is all 
about enough to comment on this one
* generator - I don't see this making sense in entry
* content - I don't see this making sense in head
* origin - I don't see this making sense in head
* id: required in entry, not in head - as it should be
* if tagline becomes summary, the fact that it's sometimes required in 
entry, but never in head - as it should be

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Nov 2004 17:14:45 +0100

Thanks a lot Antone, that is really useful work. (Why did I not think 
of doing this!(kicks himself))

I have saved the Pace from the flames of hell and have resuscitated it 
in a simpler form as PaceEntriesAllTheWayDown2 [1], which focuses only 
on the re-factoring part of the previous version.

I think this is one of these paces that like wine, will taste better 
with time. :-)

Henry

[1] http://www.intertwingly.net/wiki/pie/PaceEntriesAllTheWayDown2

On 15 Nov 2004, at 16:55, Antone Roundy wrote:

> [4] I'd say atom:info should be removed from atom:head except that 
> part of the purpose of atom:head is to make the ordering rules for 
> children of atom:feed simple, and perhaps even so.  I don't think I'd 
> be too disappointed if atom:info just disappeared.  We could (dons 
> asbestos suit) use <link rel="format-explanation" ... /> to point to 
> an explanation of the feed format if we feel the need to reserve a 
> method of educating view-sourcers.
>

---

From: Graham <[email-masked]>
Date: Mon, 15 Nov 2004 16:52:17 +0000

"The 'atom:head' is an Atom Entry"

No it isn't. Go away.

Graham

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Nov 2004 20:46:35 +0100

Stating that something is not so ok, but you will not be surprised if 
it is thought to be very weak position. If you wish to make a more 
constructive argument, which may be thought to have more weight, you 
need to find a principled reason for rejecting my proposal. I suggest 
you first reply in detail to the post by Anotone Roundy [1] and specify 
exactly where you think the difference is and why the difference is 
more important than the benefits to be gained by ignoring them.

In the end I am not bothered if an atom head is not an atom entry. If 
the difference really is fundamental we shall have learned something 
important.

Henry Story
[1] http://www.imc.org/atom-syntax/mail-archive/msg11577.html

---

From: Graham <[email-masked]>
Date: Mon, 15 Nov 2004 20:08:18 +0000

My problem with PaceEntriesAllTheWayDown is that it does not assume a 
pilchard is an Atom Entry. I suggest you first reply in detail and 
specify exactly where you think the difference is and why the 
difference is more important than the benefits to be gained by ignoring 
them.

Graham

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Nov 2004 21:25:47 +0100

If you wish to argue that a pilchard is an Atom entry, please put 
forward a pace to that effect, with supporting argument, and it will be 
my pleasure to read it and comment on it as best I can.

PaceEntriesAllTheWayDown2 is an actual Pace with supporting arguments 
from Anotone Roundy [1], which on the face of it have a lot of weight.

Henry Story

On 15 Nov 2004, at 21:08, Graham wrote:

> difference is more important than the benefits to be gained by 
> ignoring them.
>
> Graham

---

From: Henry Story <[email-masked]>
Date: Mon, 15 Nov 2004 22:15:57 +0100

On 15 Nov 2004, at 21:43, Antone Roundy wrote:
> On Monday, November 15, 2004, at 01:25  PM, Henry Story wrote:
> For the record, I'm not yet convinced.  While, as my message outlined, 
> I think there are reasonable ways to reconcile many of the differences 
> between head and entry, I did also mention a few differences that I'd 
> like to see addressed specifically.  If justification can't be given 
> for the issues with introspection, generator, content, origin, id and 
> tagline/summary, then I'm not ready to bite yet--certainly not on 
> calling head an entry, and perhaps not on merging head and entry 
> within the spec.

Yes, I had understood very well, Antone. You perfectly outlined the 
problem. I had myself not yet done this detail work with the latest 
spec, as there are some aspects of the spec that I don't completely 
understand, and as it has changed a lot. Now with 
PaceDeclareVictoryOnFormat on the table, cleaning up exercises such as 
this make a lot of sense.

For the record I am not convinced myself in being correct on this 
issue. I am convinced it is really worth investigating though.

Here I will attempt to answer these questions. These are attempts only. 
If other people have better arguments I am very open to them.

> about enough to comment on this one

I don't understand introspection that well either. But I suspect there 
would be no harm with Entries having introspection files too.

> * generator - I don't see this making sense in entry

Well, why not?  This could make a lot of sense for aggregator feeds, it 
seems to me.

> * content - I don't see this making sense in head

Why not: Add a bit of nice content to the head, for richer news readers 
may be quite nice. It works out quite nicely for James Gosling's blog 
[1]

> * origin - I don't see this making sense in head

Good one. I don't know about this.

Perhaps this would make sense in the case of a feed inside a feed: 
namely responses to someone's entry. If you think of the responses as 
constituting a feed with the original post as the "head" then this feed 
would in fact have an origin feed.

> * id: required in entry, not in head - as it should be

Mhhh. I had not realized that the id was mandatory in atom entries.

Of course if you think about using the Atom API for setting your feed 
head entry, then it would not be silly for your entry to have an id.

It may also be what is needed to allow you to change your feed head 
over time, (say you make a spelling mistake in your feed head), and yet 
be able to talk about it being the same feed.

> entry, but never in head - as it should be

Yes. But why do you really want to make it required for a feed?

Henry Story

[1] http://today.java.net/jag/

---

From: Antone Roundy <[email-masked]>
Date: Mon, 15 Nov 2004 13:43:53 -0700

calling head an entry, and perhaps not on merging head and entry within 
the spec.

---

From: Walter Underwood <[email-masked]>
Date: Mon, 15 Nov 2004 14:11:47 -0800

--On Monday, November 15, 2004 09:25:47 PM +0100 Henry Story <[email-masked]> wrote:
>
> PaceEntriesAllTheWayDown2 is an actual Pace with supporting arguments from
> Anotone Roundy [1], which on the face of it have a lot of weight.

-1

All the arguments for are based on structural similarity. That is enough
to suggest that they are related, but not enough to prove it. A shopping
cart and a baby stroller are structurally similar, but that doesn't
automatically make them related.

>From a search point of view, a feed is almost always going to be a sequence
of separate documents, each of which are indexed separately. It is certainly
possible to have a feed that represents an issue of a magazine, or all the
entries in a particular category. That feed could be treated as a document.
On the other hand, those clusters can easily be created without being a separate
feed. Use the category info, for example.

99% of the time, a feed is going to be a chronological sequence and entries
are going to be the "real" documents.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 15 Nov 2004 21:22:53 -0500

Walter Underwood wrote:
> All the arguments for are based on structural similarity. That is
> enough to suggest that they are related, but not enough to prove
> it. A shopping cart and a baby stroller are structurally similar,
> but that doesn't automatically make them related.
	Darn. Walter beat me to it... Yes, the key is that Roundy's
arguments address only the form of the two elements, not their substance or
function. This is like saying that monkeys and men are the same because they
both have two arms, two legs, etc. -- they even share common ancestry.
Admittedly, in some contexts, it is useful to see both as "primates,"
however, in most other contexts, it is best to treat them as dissimilar.
	The mere fact that we've chosen to provide a "title" in both head
and entry does not mean they are the same nor does it mean that "title"
means the same in both contexts. In fact, it does not. The "title" of a head
is not the head's title. Rather, it is the title of the feed that contains
the head. The title of an entry, on the other hand, is that of the entry
itself. One element contains data that describes itself -- the other
contains data that describes its parent and the parent of the entries in the
same feed. These differences are significant.
	I think one could argue that many of these apparent similarities are
mere artifacts of the forms we've chosen. For instance, while I think it is
natural to think of the "title" of an entry, I would not have been surprised
if the supposedly similar element in head had been called "name." It seems
odd to me to speak of the "title" for a feed. While I won't write a Pace to
propose this, I would more comfortable speaking of the "name" of a feed and
the "title" of an entry. (It's just a personal aesthetic thing...)
	Other differences are very clear to me -- even though element names
are similar. For instance, I see a great difference (under US law) between
the "copyright" of the collection which is held in head and the copyright
for a distinct entry. These two similarly named elements are just as
different from each other as they are similar. 
	Just because head and entry share a large number of similarly named
elements does not mean they are the same. Similarity of form does not imply
similarity of substance.

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 11:29:04 +0100

On 15 Nov 2004, at 23:11, Walter Underwood wrote:

>> from
> enough

There are a couple of issues here. I have written these out in length 
and publish it here, not mostly as a reply to your comment above, but 
because once I found myself writing all of this out I realized it may 
provide a helpful context in which to understand what we are doing. It 
helps both show why what we are doing may appear to be obviously false, 
surprising even, yet how this may very well be in the nature of the 
operation. It also should help focus us a little on the context we are 
dealing with, and hopefully avoid false comparisons.

1. Identity assignments can be information rich.

    Notice first of all that to prove that two things are the same you 
need not show
that their respective properties as they were known to be before the 
identity assignment was made, were the same. Very often an identity 
assignment is going to be informational rich.

Take for example Clark Kent and Superman. Clark Kent is Superman, yet 
most of the characters in the cartoon don't know this. For them Clark 
Kent is a weak geekish journalist who has trouble with physical 
exercise, and Superman is a strong powerful superhero who can fly and 
whose only weakness is kryptonite. So we could make a list of
properties that relate them such as

	Clark Kent                  Superman
     Journalist                 Superhero
	Physically weak            super strong
     Shy                        bold
	...	                       ...

And yet (Clark Kent == Superman). Those that discover this discover 
something very important. They discover for example that Clark Kent was 
only pretending to be physically weak, that he was only pretending to 
be shy, and so on for all the characteristics that may seem 
contradictory.

Notice also that if you were to tell a character in the cartoon of the 
identity they would laugh a very hearty laugh, or take you for a fool. 
This is another way to say that Identity assignments are often not 
obvious, ie. are information rich.

To convince someone of the identity of Superman and Clark Kent is not 
in any way an easy task. And neither do I think is it going to be easy 
to show that a head structure is indeed a Entry going to be easy.

2. How can one prove identity?

In the Superman/Clark Kent story we are dealing with physical entities. 
The identity of physical entities is a combination of a category of the 
physical entity and the spatio temporal position they occupy. Both 
Clark Kent and Superman are Men: if you can show that they occupy the 
same position in space you have proven that they are the same.

In the shopping cart vs baby stroller case we are both dealing with 
concepts of a functional nature for the purposes of everyday use. One 
can show that the classes are disjoint by looking at the purpose of 
both objects and finding instances of both that are different. In this 
case most instances of the concepts are indeed different, and it is 
only the rare case where one finds objects that fit both categories.

In our case we are working on a specification of a file format, to help 
interoperation between blog producers and blog consumers. The classes 
we define have no external Platonic existence outside of the work we 
are doing. So we cannot compare our definition of an Entry with the 
real thing out there. There are many other ways of cutting up the 
conceptual space as witnessed by the NewsML and other syndication 
formats.

Of course not everything goes. Atom is working in the spirit of the RSS 
formats, which is to "keep things simple". It is a format that has to 
interact with a protocol, which we also may wish to keep as simple as 
possible. This is nearly a founding principle I think behind the work 
that is being done on this group. So to find a huge amount of 
structural similarities between two constructs is a very weighty 
argument in favor of a  spec simplification. Especially if it allows 
one to express the same things as were expressed before the 
simplification.

So to conclude:
	- In the Clark Kent/Superman case identity is proven by 
spatio-temporal identity
	- in the conceptual space of the shopping cart distinction is proven 
by the
		largely distinct sets of objects that fall under each category
	- in the case of our spec there is a purely functional notion: what 
data structures do we need to create the easiest to understand spec for 
an equivalent functionality.

Writing a spec in that regard is very much like programming, which is 
perhaps why this exercise I am putting forward here may seem very 
natural and straightforward to other programmers. In programming one is 
also constantly creating classes that don't necessarily have a relation 
to something in reality, where the primary assessment of the quality of 
the code is not how it corresponds with reality, but how well it 
functions, how easy it is to read, to extend, to understand and in 
general to work with. Since it is never possible to get this right the 
first time round, we spend a lot of time on Refactoring our code, as 
has recently been so well described by Martin Fowler. The aim of that 
process is to start off with some complex code and end up perhaps with 
something that is a lot easier to read or to work with, but with 
exactly (or very nearly) the same functionality. That the code is 
equivalently functional is in part verified by testing it against a 
bunch of unit tests.

If we had unit tests for the Atom spec, it is my belief that the 
re-factoring I am proposing would hardly impact those tests.  And that 
the small changes required are amply justified by the gains achieved.

Ok, that should be enough with the theory. I'll look at the criticisms 
one by one now.

Henry Story

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 12:58:43 +0100

> however, in most other contexts, it is best to treat them as 

Monkeys and men have a lot more dissimilarities than the structure that 
goes into the head of a document and the structure that is an Entry. At 
least on mine, Roundy's, Robert  Sayre's and others analysis.

Structural similarity is of course no final criterion of identity. For 
physical bodies it is spacio-temporal identity. For structures that 
appear in specifications of the type we are dealing with, it structural 
similarity is a lot more weighty, especially if one finds no lack of 
functionality by attempting the equivalence.

> same feed. These differences are significant.

That is a good constructive point. :-)

There are I think, two different solutions to this.

1. Feed is a pair feed(head,stream)

   a) The title of the Entry that goes into the head is the title of 
that Entry.
   b) The feed has a head relationship to one and only one Entry.
	This 'head' relationship is a special relationship, which makes an 
assertion about the Feed and the Entry. This can be paraphrased as 
saying that the Entry related to the Feed by the head relationship, 
that that Entry, call it headentry, that its copyright is the feed's 
copyright, that the headeantry's title is the feed's title, etc...

2. A Feed is a Entry

  The feed *is* the Entry that is its head. This is simplest to 
understand. The
copyright of the head entry is the copyright of the feed, since that 
feed and the head Entry are the same object. A Feed in this 
conceptualization, simply is an Entry that points to other Entries.

	in programming terms

	class Feed extends Entry {
		List<Entry> entries = new ArrayList<Entry>();

		Entry getHead() {
			return (Entry)this;
		}

		List<Entry> getEntries() {
			return entries;
		}

		void addEntry(Entry e) {
			entries.add(e);
		}
	}

In both situations you end up with the same result.

note: There may be another solution I have not thought of.

> the "title" of an entry. (It's just a personal aesthetic thing...)

Yes, but I might still have seen through your tricks ;-)

> different from each other as they are similar.

Ok, so perhaps you would really like the model in which a Feed is a 
subclass of Entry.

The copyright of the Feed is the copyright of the head Entry (ie. 
itself cast as an Entry, though that cast is not really necessary, due 
to property inheritance). As new Entries are added to the Feed the 
collection of Entries is of course copyrighted under the copyright of 
the Feed.

I think you would probably really like this model. It pushes the 
simplification even further. Atom would really deserve its name: the 
Entry is the Atom of the Blogging universe.

"It's All about the Entries, Stupid!"

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 09:17:38 -0500

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

---

From: Walter Underwood <[email-masked]>
Date: Tue, 16 Nov 2004 07:48:21 -0800

> Ok, so perhaps you would really like the model in which a Feed is a

That is the normal approach for compound documents. But I still 
don't see a convincing reason. And I do favor short specs.

1. People have been working on compound documents without much success
for at least fifteen years. To me, that indicates that they are either
very hard or not very useful.

2. I have not seen a use case where a feed would be treated as an entry.
If it is common, not just possible, for a feed to be an entry, then we
need this. Otherwise, we don't. Show me the real world use cases.

3. Identity is not sufficient for something to be the same class. It is
common for the same chemical to have multiple uses, each with different
trademarks, packaging, production, and sales figures. From a business
perspective, those identical chemicals must be treated as separate
things, e.g. a dessert topping and a floor wax.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 17:16:27 +0100

> 	No. I don't like it at all.

Mhhhh. I wonder...

> obvious that I think that: "An Entry is a Feed." I do not think that 

The model I proposed as a solution to your problem and what you
are proposing is sooooo incredibly close then :-) I wonder if we are 
not talking at
cross purposes...

> can contain no entries.

"restricted subclass"? That just so much sounds like a superclass to me.
Are you sure we are not agreeing here? :-) In the Feed is a Entry model 
too an Entry contains no Entries. No difference until here it seems.

> An entry is simply a single entry feed

So you are proposing:

	(a)- an Entry is a subclass of a Feed
     (b)- an Entry is a Feed that contains one and only one Entry.

So we have a relation of inheritance and a relation of composition, 
like in the "Feed is a Entry" model.

But the way you put it, it seems a little weird, because we have a 
superclass that refers to its subclass and all kinds of weird things 
are required.

	class Feed {
		List<Entry> entries;

		void addEntry(Entry e) {
			if ((this instanceof Entry && entries.size() < 1 )
				entries.add(e);
			else if (!this instanceOf Entry)
				entries.add(e);			
		}

	}

	class Entry  extends Feed {
		
		void addEntry(Entry e) { //empty method
		}    	
	
     }
		
So where do the Entry stuff go, such as the title, etc...? In the Entry 
class or the Feed class?

> and we do

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.
Especially if you also want it to be easy to understand.

Is there any other way you could model this? Say using logic or set 
theory?

> of truth provides no gain.

As I said before, I don't think the vocabulary of accuracy or "truth" 
is a good one here. There is no Platonic reality to which we can go to 
see if our model is the "right" one. What you mean to say is

"elegance at the cost of functionality provides no gain".

And I think, as I will show below, that there is no loss of 
functionality.

> 	If PaceHeadInEntry is accepted, then conceptually, an Entry looks

Don't you then have an infinite recursion?

	<entry>
		<head></head>
		<entry>
			<head></head>
			<entry>
				<head></head>
				<entry>
				....
				....
				</entry>	
		 .. elements of entry ...
		</entry>
	</entry>

> utility, we have chosen to save a few bytes and encode an entry as:

Ok. You want to associate an Entry with the origin feed from which it 
stems.

One could easily add this in the following way

	<entry>
        <origin>the orgin entry</origin>
		the elements of the entry
	</entry>

if origin is the wrong term, we can always change it.

> think that a feed is simply a sliding-window on a stream of events.

Yes. So does what I am proposing.

> An Entry is simply a feed with a window-size of 1.

Very similar to where I am at.

> This is an important observation

Seems quite feasible with the Feed is a Entry model. In any case it 
seems quite feasible with the refactoring that I have proposed.

> intuitive if you view an entry as a single entry feed.

I find it really difficult to get my head around what you are saying. 
So it does not seem at all intuitive to me. I wonder if I am alone in 
this position?

> 	Entries are single entry feeds.

That just sounds so recursive!

> Feeds are not entries -- they are

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 11:28:52 -0500

Walter Underwood wrote:
> 1. People have been working on compound documents without much
> success for at least fifteen years. To me, that indicates that
> they are either very hard or not very useful.
	It's been much longer than 15 years. I was deep in discussions of
compound documents at Digital back in 1981 when we were just getting the
Office Automation products started (mine was ALL-IN-1). That was almost 24
years ago... If I remember right, Digital publicly published "CDA" (The
Compound Document Architecture) in '85 or '86 -- still more than 15 years
ago. Also, there was much debate about compound documents in the X.400 email
discussions in the 80's (it was such a natural thing to do with ASN.1.
Digital's CDA was defined in ASN.1). The issues hadn't been resolved at all
by the time I got to Microsoft in 1991 and found the same discussions raging
there -- OLE (Object Linking and Embedding) was just getting going. We then
went through it all again in the various HTML debates... etc. Some issues
just don't go away.
	Compound documents are very useful and very hard.

		bob wyman

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 17:54:38 +0100

Perhaps there is a third solution that won't get me into the lengthy 
debates on Feed is a Entry, which if it is going to be argued would be 
better argued separately. If possible I would like to keep the issues 
separated.

This is to point out the following. Currently you have created a head 
data structure
that has an title, an author etc. You have no problems accepting that 
the title in the head is a property of the Feed. So similarly you 
should have no problem accepting that the title in an Entry that is the 
head of a feed is the title of the feed.

Henry

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 17:14:32 +0000

On 16 Nov 2004, at 4:54 pm, Henry Story wrote:

> So similarly you should have no problem accepting that the title in an 
> Entry that is the head of a feed is the title of the feed.

It's the "an Entry that is the head of a feed" that will never get 
acceptance. I don't understand your obsession with this. If you wanted 
to create an Atom Record structure, one that is a head and the rest are 
called entries, that might make sense and would equally achieve your 
goals, wouldn't it?

Graham

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 18:30:29 +0100

On 16 Nov 2004, at 18:14, Graham wrote:

>> So similarly you should have no problem accepting that the title in 
>> an Entry that is the head of a feed is the title of the feed.
>
> to create an Atom Record structure, one that is a head and the rest 
> are called entries, that might make sense and would equally achieve 
> your goals, wouldn't it?

Perhaps we may well be agreeing. Always difficult to tell :-)

I am saying there is an Entry record structure. A feed is a pair

	feed(Entry head, List<Entry> entries)

or

	Feed1
       |------head-------> Feed1sHead ----a---->Entry
	  |------entry------> Feed1Entry1 ---a---->Entry
       |------entry------> Feed1Entry2 ---a---->Entry
       |------entry------> Feed1Entry3 ---a---->Entry

ie: we have one record structure of type Entry.
A Feed has one such record structure in the head relation to it.
And it has a list (or sequence, or whatever collection takes your 
fancy) which form
the entries of the feed.

Are we agreeing?

	Henry Story

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 12:40:02 -0500

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

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 18:41:57 +0100

Sorry I could also have given a java representation:

	class Entry {
		String title;
		Person author;
		List<Person> contributor;
		....
	}

	class Feed {
		Entry head;
		List<Entry> entries;
		//that's all folks, the rest is just methods...		
		String getTitle() {
			return head.title;
		}

		Person getAuthor() {
			return head.author;
		}

		List<Person> getContributors() {
			return head.contributor;
		}

		...
	}

Henry Story

On 16 Nov 2004, at 18:30, Henry Story wrote:

>> acceptance. I don't understand your obsession with this. If you 
>> wanted to create an Atom Record structure, one that is a head and the 
>> rest are called entries, that might make sense and would equally 
>> achieve your goals, wouldn't it?
>
>

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 17:43:01 +0000

> And it has a list (or sequence, or whatever collection takes your 

No. Using "Entry" as a broad term for a record is a nonsense. One atom 
"entry" corresponds directly to a blog entry, a head does not. Stop 
doing that.

Even then, still no. An entry is an entry and a head is random 
collection of other metadata with no collective structure or meaning - 
ie a head on its own is basically meaningless, an entry isn't.

Graham

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 18:56:09 +0100

Ok. So what is the difference between the head structure and the entry 
structure?

Henry

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 18:08:42 +0000

> Ok. So what is the difference between the head structure and the entry 

I know you are but what am I?

Graham

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 19:17:41 +0100

Ok. Graham is some new type of eliza like robot, specially designed for 
IETF working groups it seems. Quite clever.

Henry

On 16 Nov 2004, at 19:08, Graham wrote:

>> Ok. So what is the difference between the head structure and the 
>> entry structure?
>

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 18:30:32 +0000

Do you need everything explained to you?

Me: "A head structure is [this thing], while an entry structure is 
[this other thing], ergo they are different"
You: "Ok. So what is the difference between the head structure and the 
entry structure?"

cf.
Kid 1: "You're smelly"
Kid 2: "I know you are but what am I?"

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 16 Nov 2004 13:46:59 -0500

Henry Story wrote:
> So what is the difference between the head structure and the
> entry structure?
	A head structure describes a feed. An entry structure does not.

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Tue, 16 Nov 2004 11:48:24 -0700

On Tuesday, November 16, 2004, at 10:40  AM, Bob Wyman wrote:
> context provided by a single <head/> element.

I just spent a while writing an meandering exploration of this issue, 
which I won't bore you with, but in the end, I came to the conclusion 
that a feed is not an entry and an entry is not a feed.

A feed is a context in which content is published.  Sometimes it is the 
original context of the content, and sometimes it is a context in which 
content originally from another context is redistributed.  atom:head is 
a container for metadata describing the context.

atom:entry is a container for both the content and metadata describing 
the content.

I think the question is, are context and content different forms of the 
same thing, and I think the answer is no.  Although there are cases, 
like comment feeds, where the context is an entry, that's more of a 
coincidence than a description of the nature of a feed.

So assuming that we agree that content and context aren't different 
forms of the same thing, then what about the metadata describing 
content and the metadata describing context?  In other words, if Atom 
looked like this:

<context>
	<context-metadata>
		<title></title>
		<link ... />
	</context-metadata>
	<content>
		<content-metadata>
			<title></title>
			<link ... />
		</content-metadata>
		<actual-content>Here's the content</actual-content>
	</content>
</context>

... then are <context-metadata> and <content-metadata> the same thing?  
(Till now, we've been asking whether either <context> or 
<context-metadata> and <content> are the same thing, which I think 
they're not).

I, for one, don't think so, despite structural similarities.

The final question is whether, due to the structural similarities, the 
written specification would benefit from consolidation of 
<context-metadata> and <content-metadata>.

Pro:
* The spec would be shorter
* We wouldn't have to duplicate various text
* Any others?

Con:
* Where their structures diverge, it could create confusion over which 
elements are legal within context-metadata (atom:head) and 
content-metadata (atom:entry...we don't actually have a container 
within atom:entry, which is probably for the best).  Yes, I know, the 
spec will make that clear, but it won't be clear by looking at the 
index, and a less than thorough reading of the spec text itself could 
miss the details.
* Any others?

Personally, I don't think the pros are that important (nice, but not 
important), but I do think the con is.

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 19:53:17 +0100

I am telling me that Clark Kent and Superman are the same, showing you 
why, explaining how I came to the conlusion, and you just respond

	-"no it ain't"
	- Clark Kent is one thing and Superman is another so they can't be the 
same
	- or some irrelevance

Henry

---

From: Graham <[email-masked]>
Date: Tue, 16 Nov 2004 19:01:09 +0000

Your best argument amounts to "Yes they are", so lets call it quits, OK?

Graham

---

From: Antone Roundy <[email-masked]>
Date: Tue, 16 Nov 2004 12:25:54 -0700

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 20:29:33 +0100

> Your best argument amounts to "Yes they are", so lets call it quits, 

Not at all. My best arguments have best been expressed by Antone Roundy 
in a previous mail [1]. I came to the same conclusion by trying to 
build OWL models of Atom [2], which I am currently implementing in an 
open source blog editor, named BlogEd [3], using the Sesame RDF 
database. I have so far had no trouble at all using that model.

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11577.html
     and my reply to his questions at
     http://www.imc.org/atom-syntax/mail-archive/msg11604.html
[2] http://bblfish.net/work/atom-owl/
[3] see https://bloged.dev.java.net/

---

From: Henry Story <[email-masked]>
Date: Tue, 16 Nov 2004 20:45:27 +0100

That [1] is indeed the correct way to respond, Antone. Thanks.

Clearly there are differences, otherwise everybody would long ago have 
realized that
they are the same thing. This is again the Clark Kent vs Superman story.

But as Antone specifies in that mail, the differences are not 
insurmountable. I have tried to answer some of his most difficult 
questions in an e-mail [2].

I am following the context debate to see if that helps illuminate a 
deep difference that I had not yet perceived.

Henry

[1]  http://www.imc.org/atom-syntax/mail-archive/msg11577.html
[2]  http://www.imc.org/atom-syntax/mail-archive/msg11604.html

---

From: Antone Roundy <[email-masked]>
Date: Tue, 16 Nov 2004 14:02:07 -0700

Okay, time to respond to this message:

> would be no harm with Entries having introspection files too.

My vague impression is that an entry has no need for introspection.  
Comments anyone?

> Well, why not?  This could make a lot of sense for aggregator feeds, 
> it seems to me.

The aggregator is responsible to ensure that it's output is well-formed 
and valid, regardless of what it gets from its source feeds.  I'd say 
that makes it the generator.  (That might be an argument for removing 
atom:generator from atom:head when aggregating if PaceHeadInEntry is 
accepted).  Conceptually though, you're right, SOMETHING is generating 
the entry.

> Why not: Add a bit of nice content to the head, for richer news 
> readers may be quite nice. It works out quite nicely for James 
> Gosling's blog [1]

Okay, I'll buy the argument that sometimes the context can contain 
content.  A comments feed is probably the best example.  But the nature 
of that content feels different--or at least like it would often be.  
The fact that it's expendable at the feed level but central to an entry 
is part of that.  In some cases, feed/head/content would be more like 
metadata than content.

> constituting a feed with the original post as the "head" then this 
> feed would in fact have an origin feed.

If PaceHeadInEntry is adopted, I expect we'll drop atom:origin, so this 
won't be an issue.

> head entry, then it would not be silly for your entry to have an id.

I'm not subscribed to the protocol list, and haven't kept an eye on the 
API, so perhaps someone else could speak to this better than me.  Can 
the API be used to edit atom:head?  If so, how does one identify which 
feed's head is being manipulated?  I'm sure you COULD have a different 
URI for each feed, but I would also expect that the API would support 
manipulating multiple feeds via the same URI.  So it's easy to imagine 
both cases where you would and wouldn't need a feed ID.  Should a feed 
ID be required?

>> * if tagline becomes summary, the fact that it's sometimes required 
>> in entry, but never in head - as it should be

I don't, which is what I meant by "as it should be".

It looks to me like MOST of the structural differences between 
atom:head and atom:entry can be resolved, but I still question whether 
there's enough value in merging their descriptions in the spec to 
justify the work for the editors, the messiness of having to explain of 
the differences, and the risk of it causing misunderstandings.

Ultimately though, IF we were to alter the structure of head and entry 
to make them VERY similar, I wouldn't put up a stink about it either 
way.

---

From: Tim Bray <[email-masked]>
Date: Tue, 16 Nov 2004 19:23:41 -0800

> questions in an e-mail [2].

Since they are different on the surface, and most people are going to 
easily understand that they are different, I just don't see the 
benefits from peering deep to find the essential sameness.   -Tim

---

From: Henry Story <[email-masked]>
Date: Wed, 17 Nov 2004 09:30:26 +0100

Ok. I agree that there are arguments in favor and arguments against.

I will go back to working on BlogEd[0], keeping in mind Anotone 
Roundy's points [1][2], and see if the simplification that I am 
proposing here, and that is implemented in BlogEd, really do end up 
creating any problems or confusions. I have not come across any yet.

   In the meantime I'll leave the pace open. I think it should be 
revisited later. The way things are going [3] things are going to be 
getting a lot more complicated in this spec really fast.

[0]  https://bloged.dev.java.net/
[1]  http://www.imc.org/atom-syntax/mail-archive/msg11577.html
[2]  http://www.imc.org/atom-syntax/mail-archive/msg11673.html
[3]  http://www.imc.org/atom-syntax/mail-archive/msg11662.html

---

From: Walter Underwood <[email-masked]>
Date: Wed, 17 Nov 2004 09:11:09 -0800

How about an approach that is specific to the defaulted values?

1. The feed metadata is split into feed-meta and entry-meta-defaults.
2. Each item in the entry metadata is specified as defaultable or not.
3. Entry metadata can be explicitly "unset" to not have a value, perhaps
by using an empty element with an attribute to make it clear.

Perhaps this has been proposed at one point. If so, I missed it amongst
all the other discussion.

This is orthogonal to whether feeds and entries are kinds of each other.
If they are, the feed-meta and entry-meta will need to be coordinated.

wunder

--On Wednesday, November 17, 2004 09:30:26 AM +0100 Henry Story <[email-masked]> wrote:

> I will go back to working on BlogEd[0], keeping in mind Anotone Roundy's points [1][2], and see if the simplification that I am proposing here, and that is implemented in BlogEd, really do end up creating any problems or confusions. I have not come across any yet.
>
>    In the meantime I'll leave the pace open. I think it should be revisited later. The way things are going [3] things are going to be getting a lot more complicated in this spec really fast.
>

--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Henry Story <[email-masked]>
Date: Wed, 17 Nov 2004 19:07:10 +0100

I do want to emphasize that I don't think PaceEntriesAllTheWayDown2 
forces one to accept the FeedIsAEntry model. It does allow it, so it 
may be a reason for some people to support it. As such I will respond 
to your questions here.

On 16 Nov 2004, at 16:48, Walter Underwood wrote:

> That is the normal approach for compound documents.

Yes. It is probably not much more than the very well known composite 
pattern used in OO programming [1]

> But I still
> don't see a convincing reason.

Here are some:
- it could very well simplify the API. If there is only one thing or 
two that we are dealing with then we don't need a lot of special cases.
- It would further simplify the spec. The spec for Feed would just say: 
has all the properties of an Entry and in addition can contain Entries.
- It would allow you to present a Feed of Entries and responses to 
those. (Though one could also disallow this explicitly.)

	<feed>
		<title>my feed</title>
		<author><name>Henry Story</name></author>
		<copyright>Creative commons licence</copyright>
		<entry>
			<title>my first entry</title>
			<content>This is great</content>
		<entry>
		<feed>
			<title>SuperMan is Clark Kent</title>
			<content>The other day I saw Clark Kent fly out of the window.
			He changed his suit in mid air, and saved the child that was
			about to get crushed by an out of control Atom robot</content>
     		<author><name>Henry Story</name></author>
			<entry>
				<title>That can't be</title>
				<author><name>Graham</name></author>
				<content>Superman can fly. Clark Kent can not. A thing can't
				have two inconsistent properties. Duh!</content>
			</entry>
			<entry>
				<title>I know how we could test this!</title>
				<author><name>Antone Roundy</name></author>
				<content>What you say is increadible Henry. But I know how
				we could find out. Superman has a deadly fear of kryptonite, that
				humans don't have. I happen to have some. We just need
				to give some to Clark Kent.
				</content>
			</entry>
		</feed>
	</feed>

> And I do favor short specs.
>

Interesting. Perhaps they were trying things that were a lot more 
difficult.
In any case the Composite pattern is applied all over the place, with a 
lot of success.

> need this. Otherwise, we don't. Show me the real world use cases.

I think the above use cases are amply sufficient to explain the 
advantage.

> things, e.g. a dessert topping and a floor wax.

Yes. I am many things. I am Henry Story and I am a mass of cells.

We can start splitting hairs all over the place and also end up with a 
spec 500 pages long. Or we could end up being simple, and up getting a 
really tiny, consistent and powerful spec out there. Small is 
beautiful.

> wunder

[1] http://patterndigest.com/patterns/Composite.html