Subject: Re: Call for final Paces for consideration: deadline imminent

From: "David Powell" <[email-masked]>
Date: Sat, 5 Feb 2005 17:27:34 -0000

>I disagree, as I've said before. The only literal interpretation is 
   >that you can't serve the same entry twice with the same id. We know it 
   >doesn't mean that, but the spec just doesn't define in which axis 
   >"unique" is meant to apply.

I think that the problem is that the term 'entry' is used to refer to two different concepts.

An entry id is identifying the underlying entry resource.

But something like an entry title, I would think of as a property of the 'entry instance'.

Currently we don't distinguish between entries and entry instances, and I think that this creates a lot of ambiguity.

Although we could keep the model we have (let's call it the 'mutable entries' model), it isn’t  clear on a number of issues.  Eg, if an old version of an entry has some property that isn’t  present in a newer version, does that property still apply to the new instance?  The answer is presumably 'no' but it isn't obvious from the spec.  Under a 'multiple instances' model, it would be implicit.

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Sat, 5 Feb 2005 18:53:02 +0100

On 5 Feb 2005, at 18:27, David Powell wrote:
> Currently we don't distinguish between entries and entry instances, 
> and I think that this creates a lot of ambiguity.

I agree with this analysis. But I think one can deal with it.
A simple OWL ontology would make these things very clear.

> Although we could keep the model we have (let's call it
> the 'mutable entries' model), it isn’t  clear on a number of issues.  
> Eg, if an old version of an entry has some property that isn’t  
> present in a newer version, does that property still apply to the new 
> instance?  The answer is presumably 'no' but it isn't obvious from the 
> spec.  Under a 'multiple instances' model, it would be implicit.

It is easiest if one starts off deciding that no properties get
inherited. Some properties do seem to clearly require inheritance
such as the author, as one would expect all the versions of an
entry to have the same author. But the amount of debating that
this would require would not be worth the effort. The id property
does the job very nicely and inconspicuously.

At one point I had thought that properties such as author should
be directly attached to the id construct, since they are immutable.
But then one gets into problems of which are essential and which non
essential properties...

Henry Story

---

From: Eric Scheid <[email-masked]>
Date: Sun, 06 Feb 2005 14:10:23 +1100

On 6/2/05 4:27 AM, "David Powell" <[email-masked]> wrote:

> Although we could keep the model we have (let's call it the 'mutable entries'
> model), it isn’t  clear on a number of issues.  Eg, if an old version of an
> entry has some property that isn’t  present in a newer version, does that
> property still apply to the new instance?  The answer is presumably 'no' but
> it isn't obvious from the spec.  Under a 'multiple instances' model, it would
> be implicit.

+1

now go write a pace, and quickly

e.

---

From: David Powell <[email-masked]>
Date: Mon, 7 Feb 2005 09:04:18 +0000

> e.

My plan was to take the Atom Concepts section of the document, add
"Entry Instance" to it, and do a bit of find/replacing to make it
clear that properties are properties of the instance and id is the id
of the Entry itself. Unfortunately there is no Atom Concepts section,
so I have not had time to do this. Currently the only definition of
what an entry or feed is in the informal introduction in the first
couple of sentences of the specification.

I think we should to insert an "Atom Concepts" section before the
current section 2 so that we can properly explain the important terms
in Atom before we can talk about how to represent them in the format.

Can we fix this as an editorial issue? There is enough confusion about
entries and ids amongst the working group, nevermind the readers.

-- 
Dave

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Feb 2005 08:45:38 -0800

>entries and ids amongst the working group, nevermind the readers.

Yes and no. Yes if it is truly editorial with no technical 
side-effects; no if the changes have technical side-effects. For 
example, I see some people sliding the definition of "feed" towards 
something that doesn't match well the elements and attributes that we 
have made for feeds. Such a change would definitely be not OK.

My proposal is that we add text copping to the fact that "feed" and 
"entry" and "id" were difficult for the WG to define precisely. Being 
honest is probably of more value to future implementers than us 
narrowing the definition down more than is warranted by the rest of 
the format document.

--Paul Hoffman, Director
--Internet Mail Consortium