Subject: Principled Reasoning. was: PaceAggregationDocument posted

From: Henry Story <[email-masked]>
Date: Tue, 1 Feb 2005 14:08:33 +0100

What is really needed here is some principled reasoning [1]. Otherwise 
we will be left
clambering in the dark caverns of our individual prejudices.

I suggest that when people make statements in favor or against 
something, principled reasons
be given. It should be possible then to  discuss the validity of the 
claims (are things truly
the way stated), and the strength of the principles on which they rely.

Perhaps it would also be useful to remember that the number of ways 
things can be is
exceedingly large, and that often wars about what seem to be 
incompatible perspectives
in the end turn out to be complimentary.

Henry Story

[1] see for example "The Nature of Rationality" by Robert Nozick
     http://www.amazon.com/exec/obidos/tg/detail/-/0691020965/

On 1 Feb 2005, at 05:24, Robert Sayre wrote:
> Antone Roundy wrote:
>
>> My preferences:
>>
>> +1: Current draft or PaceAggregationDocument (with or without 
>> atom:feed/atom:head and with or without metadata for atom:aggregation 
>> (atom:aggregation/atom:head?))
>> +0.5: PaceFeedRecursive without any more indirection than we already 
>> have, and only one level of recursion
>> -0.8: Real RDF
>> -1: PaceFeedRecursive as it stands (no extra indirection, but 
>> unlimited levels of recursion)
>> -1.5: "add an attribute to atom:entry that indicates whether it 
>> refers to an instance of entry or another feed"
>> -2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
>> atom:content
>
>
> Cool, great to getting to know you better.
>
> I'd like to add the following:
>
> vi and Emacs suck equally. Visual Studio is surprisingly elegant when 
> you get to thinking about it.
>
> Scheme and Java suck equally. Common Lisp is surprisingly elegant when 
> you get to thinking about it.
>
> Python and Perl suck equally. Ruby is surprisingly elegant when you 
> get to thinking about it.
>
> OS X and Windows suck equally. Linux is surprisingly elegant when you 
> get to thinking about it.
>
> Robert Sayre
>

---

From: Graham <[email-masked]>
Date: Tue, 1 Feb 2005 17:49:11 +0000

> in the end turn out to be complimentary.

+1

Graham

---

From: Antone Roundy <[email-masked]>
Date: Tue, 1 Feb 2005 13:05:18 -0700

On Tuesday, February 1, 2005, at 06:08  AM, Henry Story wrote:
...
Without taking the trouble to purchase and read the book you pointed 
to, here is my reasoning:

>>> atom:feed/atom:head and with or without metadata for 
>>> atom:aggregation (atom:aggregation/atom:head?))
Stable paths to the elements of a feed.  Greatest simplicity--certainly 
the way that I implement my code, these are the simplest.

>>> have, and only one level of recursion
Less stable paths to elements since you don't know in advance whether 
the entries will be in the outermost feed, or whether some or all of 
them will be inside another feed layer.

>>> -0.8: Real RDF
I think we've discussed this one enough--RDF adds overhead that I don't 
value.  Others do.  I don't.

>>> unlimited levels of recursion)
I don't want to have to deal with the added complexity of potentially 
unlimited recursion, nor do I see value in allowing it.  Sure, it can 
show you the long list of feeds that an entry traversed to get from its 
original feed to the current feed, but for those who value that more 
than I do, there MUST be a better way to do it.

>>> refers to an instance of entry or another feed"
I'm not entirely sure what is intended by this, but it sounds like a 
combination of unlimited recursion and not even knowing whether and 
entry is an entry or a feed without examining it's attributes.  I 
assume this is basically "a feed is an entry, so let's use the same 
element for both"?

>>> -2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and 
Potentially unlimited recursion, and potentially significantly more 
connections required to get a feed.  This may not be a big deal to 
applications that don't hand of HTML content to some widget for 
handling, and thus have to handle the details of loading images and 
such themselves, but for applications that do, it's much simpler to be 
able to get everything that they need to manipulate with one request 
and be done with it. We already have indirection for <content>, which I 
personally would be happier without. I'd like to avoid adding more.

---

From: Antone Roundy <[email-masked]>
Date: Wed, 2 Feb 2005 18:18:58 -0700

On Tuesday, February 1, 2005, at 01:05  PM, Antone Roundy wrote:
> and be done with it. We already have indirection for <content>, which 
> I personally would be happier without. I'd like to avoid adding more.
>
Having looked at PaceEntriesElement, my perspective on this has changed 
slightly--indirection at atom:feed would be good, but by using link, 
not recursive feeds.  The blog post and comments use case is indeed one 
that isn't addressed by the current draft.  I think that building the 
ability to stuff a whole hierarchical forum into a recursive feed into 
the core format would add an unnecessary burden of complexity for 
people who  just want flat feeds like what we've been working with to 
this point.  Linking to a feed of comments from an entry (whether a 
blog or forum post) would be a simple way to enable such hierarchical 
organization without making the format more complex.  So, rather than 
this:

<feed>
	<id>1</id>
	<entries>
		<feed>
			<id>2</id>
			<content />
			<entries>
				<entry />
				<entry />
			</entries>
		</feed>
		<entry />
		<entry />
	</entries>
</feed>

You could do this:

<feed>
	<id>1</id>
	<entry>
		<content />
		<link rel="comments" type="application/atom+xml" ... />
	</entry>
	<entry />
	<entry />
</feed>

and:

<feed>
	<id>2</td>
	<entry />
	<entry />
</feed>

That's been suggested before, but for some reason hasn't been pursued 
vigorously enough to get into the current draft.  What's missing is 
that the content of the entry that's at the top of the second feed is 
missing from the feed.  According to my mental model of a feed, the 
correct thing to do would be to put something like <link rel="about" 
href="URL of entry" /> into feed 2's head.  But that would be too 
inconvenient, so I'd rather allow atom:content and atom:summary in 
atom:feed for these cases.

And lest anyone say "See! A feed is an entry!", I still don't see it 
that way.  Instead, I see this as a convenient way to spawn a feed 
related to an entry when appropriate, and a feed has been given some of 
the attributes of an entry for convenience.

---

From: "Jeremy Gray" <[email-masked]>
Date: Wed, 2 Feb 2005 18:16:28 -0800

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]] On Behalf Of Antone Roundy
> Sent: Wednesday, February 02, 2005 5:19 PM
> To: [email-masked]
> Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted

--snip--

> And lest anyone say "See! A feed is an entry!"

I'll do it. See! A feed is an entry.

Not exactly as you've specified it, nor exactly as David has, either, but it
is very much true, captures things that have not yet been captured in the
spec, and still has the potential to simplify the spec at the same time. All
that's needed now are a few open minds.

I hope to respond in more detail on this later, but I've only taken one
reading pass through David's Pace so far and my time for the evening is
being rapidly sapped. :(

Jeremy Gray

---

From: "Jeremy Gray" <[email-masked]>
Date: Wed, 2 Feb 2005 18:54:29 -0800

Sorry, I just re-read my last message and realized that I should have said
"Robert" and not "David". I've been in a bit of a rush trying to catch up on
all of this. :)

Jeremy Gray

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jeremy Gray
Sent: Wednesday, February 02, 2005 6:16 PM
To: [email-masked]
Subject: RE: Principled Reasoning. was: PaceAggregationDocument posted

--snip--

Jeremy Gray

---

From: Henry Story <[email-masked]>
Date: Thu, 3 Feb 2005 11:37:15 +0100

Thanks these are much more helpful in working out the 
Principles/requirements
that guide your thinking.

Here are two requirements that make sense to me and seem close to giving
the same results in preferences that you have:

P1. Atom documents should be easily parsable.
P2. Atom documents should be easily updatable.

I think P2 is especially difficult for a format that would be recursive
such as

    feed
      entry1
      entry2
         entry response1
			entry response1.1
         entry response2

as it might force updates to add xml to the middle of an xml document
and so force the whole document to be regenerated. Placing entries in
a sequence and having them refer to each other by reference
makes it much easier to update your original document.

In RDF this would be similar to the TRiX or the RPV (presented by
Tim Bray) proposals [1].

And this comparison may lead us to see perhaps how to find an
agreement with the intuitions behind the paceFeedRecursive or "Entry
is a subclass of Feed" type proposals. Those proposals are put
forward from the point of view of:

P3. Simple is beautiful

But perhaps the simplicity that is searched for there is a
simplicity in the model. Indeed from a programmatic point
of view nothings is quite as beautiful as a nice recursive
algorithm. But perhaps we can have both points of views live
happily together, and perhaps the rdf experience points out
how to do this: by separating the syntax from the model.

Let us imagine we have a nice and simple model where
for example a Feed is a subclass of an Entry. We could
present this model very precisely in an OWL ontology in a
recursive way.

But we could then limit the ways to write out this model
with a Relax NG schema. Atom would then have 1. a simple model
and 2. a simple syntax.

Perfection would then be had by making absolutely clear
that the model is a model of the syntax allowed by the relaxng
compliant document, by making sure the relaxng compliant document
also be a rdf/xml document.

Henry Story
http://bblfish.net/

[1] http://www.fakeroot.net/sw/rdf-formats-20040717/#rpv

On 1 Feb 2005, at 21:05, Antone Roundy wrote:
> Stable paths to the elements of a feed.  Greatest 
> simplicity--certainly the way that I implement my code, these are the 
> simplest.
>
>>>> +0.5: PaceFeedRecursive without any more indirection than we 
>>>> already have, and only one level of recursion
> I think we've discussed this one enough--RDF adds overhead that I 
> don't value.  Others do.  I don't.
>
> show you the long list of feeds that an entry traversed to get from 
> its original feed to the current feed, but for those who value that 
> more than I do, there MUST be a better way to do it.
>