Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Henry Story]

I would just like to revisit this question, because it will help clarify
the "alternate" relation.
On 1 Mar 2005, at 11:39, Henry Story wrote:
On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
My thinking goes like this,
 - Is there a difference between an entry and the chunk of XML you 
see in a feed?
The question is vague and open to many interpretations, but I'd go for 
a yes.


- If there is, it will be in the same way there is a difference 
between a resource and a representation in web architecture.
Yes indeed that is the difference as I read it here [1].
I would like to be a little more specific now. If I take the following
entry from the format 06 spec
  
  Atom-Powered Robots Run Amok
  http://example.org/2003/12/13/atom03"/>
  urn:uuid:1225c695-cfb8-4ebb--80da344efa6a
  2003-12-13T18:30:02Z
  
Then we can say that the above Entry is a representation of the
 resource.
Now my current reading of "alternate" is that this Entry representation
had an "alternate" representation at 

at the time this entry representation was valid (2003-12-13T18:30:02Z)

Future representations of the 

resource may not have an "alternate" representation at that URL.

In which case perhaps the language of the "alternate" relation is a 
little
misleading

[[
The value "alternate" signifies that the IRI in the value of the href 
attribute identifies an alternate version of the resource described by 
the containing element.
]]

I think the above is much stronger than what a lot of people will agree 
to.

If I am reading correctly "the resource described by the containing 
element"
would be the  resource 
in the
example case.

So that our example xml would be saying that
 is an alternate version of 
, which is a lot 
stronger than what we want to say, since
we want to allow for domains being hijacked, dying, etc..

I think is much more precise to say that this representation
of  (the entry above) is 
an alternative representation of  
also.

Here we would be saying something that is true and helpful.
So perhaps the following would be better
[[
The value "alternate" signifies that the containing element is an 
alternative
representation of the IRI in the value of the href attribute.
]]

Henry Story
[1] http://www.w3.org/TR/webarch/#URI-persistence

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Eric Scheid]

On 1/3/05 9:39 PM, "Henry Story" <[EMAIL PROTECTED]> wrote:

> On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
>> Graham, Eric,
> 
> Ok since the above chickened out of answering your questions above,
> I'll do so myself.

My apologies: I didn't see the second part of that email. I thought the
extent of Bill's email was the bit addressed to the chairs/editors.

In summary response, I agree with Bill -- entries are resources, s
are representations. There is a notional construct thing we call an 'entry',
and there is an XML representation of that thing.

The spec shouldn't disallow multiple instances of s with the same
, however as a compromise I suggest the spec might use the SHOULD
qualifier ... that is,  instances SHOULD NOT have multiple s
with the same .

What this means is that if you have a good reason to do so, and you realize
that there are a lot of dumb aggregators out there that will choke, and
that's ok by you, then go ahead.

e.

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Henry Story]

On 20 Feb 2005, at 13:25, Bill de hÓra wrote:
Graham, Eric,
Ok since the above chickened out of answering your questions above, 
I'll do so
myself.

My thinking goes like this,
 - Is there a difference between an entry and the chunk of XML you see 
in a feed?
The question is vague and open to many interpretations, but I'd go for 
a yes.


- If there is, it will be in the same way there is a difference 
between a resource and a representation in web architecture.
Yes indeed that is the difference as I read it here [3].
- If you *don't* think a difference exists between an entry and the 
chunk of XML you see in a feed, there may be things you can't sensibly 
say [1]. For example if we disallow multiple appearance of an id in 
one feed we might as well disallow multiple appearance of an id across 
all feeds, for consistency. That, or document our spec's private 
definition of the word "unique".

- If you *do* think a difference exists between an entry and the chunk 
of XML you see in a feed, there may be some practical limitations. For 
example we will want to ask what's the difference operationally 
between two Entries that have been assigned the same id and the 
appearance of two entries with the same in an Atom document that 
represent the Entry at different states? What's the test that 
distinguishes between those two cases?
Here you raise a good question. But the way you ask it makes me think 
that
behind this question lurks a deep skepticism on our ability to think
historically at all.

The answer is simple: there is no one unique test. But this does not 
entail
that the distinction is not a perfectly good one that we can use. Think 
about
our historical knowledge.
	How do you know that you are the person with a certain social security
number? You may pull out your social security card, but a skeptic could 
go on to
argue that this card may be forged. Or they could argue that the card 
is real
but that you have taken on the appearance of the person to whom it 
really
belonged. You may then point to all the people around you who have 
known you
for a long time, your school teacher, your family, your friends, etc. 
And this
usually helps a lot, indeed is usually considered to be the basis of 
knowledge
of your identity. You don't get absolute philosophical certainty, but 
you do
get knowledge, even though at each point a case could be constructed in 
which
one was wrong to go by that evidence to reach that conclusion. But this 
is
a well known problem in epistemology, and I would recommend reading the 
late
Robert Nozick's book "Philosophical Explanations" [4] to help 
understand how
to navigate that particular minefield.

So here are some ways you would go about finding out if two entries 
with the
same id (the functional id I keep speaking about, the one that acts the
way a social security number works to identify you):

  - You could simply ask the author if these are the same entry. Did he 
go
 to the earlier representation of the entry by a series of 
transformation steps to
 the later representation? The types of steps one would think of are: 
fixing
 spelling mistakes or grammatical errors, correcting a bad expression 
of the
 thought, ...
  - The author is not the only one to determine the identity of the 
entry.
  Once people start reading and commenting on an entry, they in part 
act to
  constrain what the identity relation of an entry is. An author who 
would
  use completely unpredictable identity relations would confuse his 
readers,
  would reduce the point of replying to his posts or reading them. Ie. 
He would
  make it difficult to distinguish his posts from junk.


- That we can start sending multiple representations of a resource 
each marked as so inside another single representation I suspect 
extends web architecture. I looked and didn't see any support for this 
idea in AWWW.  Whether it's tunneling, abuse, or a new application 
layer I don't know.
I suspect that if this had been a problem in web architecture, it would 
have been
noticed long ago. The above seems to be saying that the web can only 
speak about the
present. But it clearly can speak about the past as well. Just check 
out the XML-HR
standard. When I write a resume using that format, I am writing a 
document which describes another resource's (me) history. If one 
suspect that there is something
so fundamentally wrong with web architecture, then this is not the 
forum to discuss
that. One should go to the web arch forums. Here we should assume that 
there is no
such problem. Specialization of tasks demands that.

- Maybe the WebDAV folks have been through this. HTTP has no obvious 
use cases or support for serving up resource state in one entity body 
rather than as a stream of entities.

My opinion is that keeping XML representations of entries distinct 
from entries affords the most flexibility and maximises internal 
consistency for the kind of use cases feeds support [2]. It will be an 
arbitrary limitation of la

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Henry Story]

I like the way you put the question below. It is indeed very clear.
But it does not seem incompatible with us adding some text now in the
spec that acknowledges that we have not yet answered the questions you
pose. I would surround this text  with square brackets [] just as we
have done with other parts of the spec that are not finished. I
certainly prefer this to text being added that suddenly cuts the issues
arbitrarily.
If I follow your reasoning correctly whatever way one cuts this, one is
left with a problem. These problems had not been acknowledged clearly
before, so  there is no guarantee that this group has in fact agreed on
anything with respect to this. The problem therefore does either need to
be resolved or it has to be acknowledged. I propose we acknowledge the
problem in the just-about-to-come-out revision of the spec with language
with an effect similar to the following:
[ whether more than one entry with the same id can appear in a feed 
document
  has not yet been resolved ]
rather than go the way Tim Bray was thinking of going, namely:
PaceRepeatIdInDocument
Lots of discussion, more -1's than +1's.
DISPOSITION: No consensus, close it.  But now we have a problem, in 
that this removed ambiguity in one direction, just closing it leaves 
the ambiguity.  So the only logical conclusion is that the WG is 
directing the editors to put language in that explicitly forbids 
entries with duplicate  in an .
I would like to answer your questions below, but I would rather wait to
see where the whole new version of the spec has put us before embarking 
on
the debate.

I gather it should be ready any time now.
Henry Story
On 23 Feb 2005, at 12:10, Bill de hÓra wrote:
Henry Story wrote:
Bill de hÓra then responded:
[[
-1. That is of no little value to a user of the spec. Also, do read 
what I said earlier in this thread - I'm not looking to resolve 
ambiguity, I'm looking to specify what's going to be ambiguous.
]]
To which I reply:
This is getting to be a very subtle distinction, and I am having 
trouble following.
If you allow multiple entries with the same id in a feed, there's no 
straightforward way to determine whether the feed provider has 
defective id distribution. All you do is say these entries represent 
states of the same thing.

If you don't allow multiple entries with the same id in a feed, then 
feeds become a special aggregation case since you almost certainly 
want to allow multiple entries with the same id across feeds.

This has to do with webarch because the use case for multiple 
representations (entries) carried inside other representation (feeds) 
and from multiple authorities aren't covered by it, and bring up such 
issues as the above,  eg, I have no idea whether Atom/RSS represents a 
new layer above or an extension to, current app protocols. Aside from 
overall architecture I sepculate that can be expected to have 
implications for trust, caching, security and design of 
implementations. So far we've only really talked about the effect on 
client aggregators in presenting entries to users. *

What's subtle about that? :)
cheers
Bill
* This is the point where I start to see where Rob Sayre is coming 
from with WebDAV.

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Henry Story wrote:
Bill de hÓra then responded:
[[
-1. That is of no little value to a user of the spec. Also, do read what 
I said earlier in this thread - I'm not looking to resolve ambiguity, 
I'm looking to specify what's going to be ambiguous.
]]

To which I reply:
This is getting to be a very subtle distinction, and I am having trouble 
following.
If you allow multiple entries with the same id in a feed, there's no 
straightforward way to determine whether the feed provider has defective 
id distribution. All you do is say these entries represent states of the 
same thing.

If you don't allow multiple entries with the same id in a feed, then 
feeds become a special aggregation case since you almost certainly want 
to allow multiple entries with the same id across feeds.

This has to do with webarch because the use case for multiple 
representations (entries) carried inside other representation (feeds) 
and from multiple authorities aren't covered by it, and bring up such 
issues as the above,  eg, I have no idea whether Atom/RSS represents a 
new layer above or an extension to, current app protocols. Aside from 
overall architecture I sepculate that can be expected to have 
implications for trust, caching, security and design of implementations. 
So far we've only really talked about the effect on client aggregators 
in presenting entries to users. *

What's subtle about that? :)
cheers
Bill
* This is the point where I start to see where Rob Sayre is coming from 
with WebDAV.

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Henry Story]

On 23 Feb 2005, at 08:53, Henry Story wrote:
On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
Sorry that should have been "Paul Hoffman wrote":
My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively 
want the model the way the document currently reads, other actively 
want the model to be different, and most don't care about the 
differences between those two.
That is a very diplomatic way of putting things :-) since we don't 
know what
you mean by the way the document currently reads.

There was an attempt to resolve the ambiguity of how many times an 
entry with
the same id can appear in a feed document. The resolution of this 
ambiguity in
favor of one model over the other at such a late stage in the game can 
seem
like an attempt by some to impose their reading of the spec.

I would be in favor of not resolving the ambiguity but of highlighting 
it
with text such as

[ whether more than one entry with the same id can appear in a feed 
document
  has not yet been resolved ]
Bill de hÓra then responded:
[[
-1. That is of no little value to a user of the spec. Also, do read 
what I said earlier in this thread - I'm not looking to resolve 
ambiguity, I'm looking to specify what's going to be ambiguous.
]]

To which I reply:
This is getting to be a very subtle distinction, and I am having 
trouble following.

I am not trying to resolve ambiguity. The text above is looking to 
point out
in the text what is ambiguous.

The hope is that questions such as the ones you are asking in this 
thread,
and work on the protocol, will help clarify the ambiguity and perhaps 
resolve
it to everyone's satisfaction.

This would have the virtue of not taking sides in the debate and of not
forcing one reading by default.
We can then move onto the protocol issue, which I think will force the
clarification of what an Entry is, and thereby  the arguments as to why
one reading or the other should be preferred.
Henry Story

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Henry Story wrote:
I would be in favor of not resolving the ambiguity but of highlighting it
with text such as
[ whether more than one entry with the same id can appear in a feed 
document
  has not yet been resolved ]
-1. That is of no little value to a user of the spec. Also, do read what 
I said earlier in this thread - I'm not looking to resolve ambiguity, 
I'm looking to specify what's going to be ambiguous.

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Henry Story wrote:
On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want 
the model to be different, and most don't care about the differences 
between those two.

That is a very diplomatic way of putting things :-) since we don't know 
what
you mean by the way the document currently reads.
Ftr, I didn't say that, Paul Hoffman did. Please be careful with your 
attributions!

cheers
Bill

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Henry Story]

On 23 Feb 2005, at 00:18, Bill de hÓra wrote:
My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want 
the model to be different, and most don't care about the differences 
between those two.
That is a very diplomatic way of putting things :-) since we don't know 
what
you mean by the way the document currently reads.

There was an attempt to resolve the ambiguity of how many times an 
entry with
the same id can appear in a feed document. The resolution of this 
ambiguity in
favor of one model over the other at such a late stage in the game can 
seem
like an attempt by some to impose their reading of the spec.

I would be in favor of not resolving the ambiguity but of highlighting 
it
with text such as

[ whether more than one entry with the same id can appear in a feed 
document
  has not yet been resolved ]

This would have the virtue of not taking sides in the debate and of not
forcing one reading by default.
We can then move onto the protocol issue, which I think will force the
clarification of what an Entry is, and thereby  the arguments as to why
one reading or the other should be preferred.
Henry Story

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Paul Hoffman wrote:
At 12:25 PM + 2/20/05, Bill de hÓra wrote:
Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best taken 
forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, as 
that's the more difficult case.

My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want the 
model to be different, and most don't care about the differences between 
those two.

When the next draft of the document comes out, this can be rehashed 
again in the WG if there is a single specific Pace that gives a complete 
delta from that draft.

However, that Pace will not necessarily hold up us going to IETF last 
call, unless our AD wants it to. This kind of "does the model say A or 
B" discussion is quite appropriate in IETF last call, where folks who 
have very different model ideas might join in.
Ok, my opinions above stand, irrespective of when you think the 
discussion should be scheduled; there's an architectural issue wrt how 
Atom layers Web representations and there are tradeoffs to be 
considered. Anyway, I thought we were done with Paces.

cheers
Bill

Re: Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Paul Hoffman]

At 12:25 PM + 2/20/05, Bill de hÓra wrote:
Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best 
taken forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, 
as that's the more difficult case.
My read of the mailing list is that people are simply looking at the 
model described in the document differently. Some folks actively want 
the model the way the document currently reads, other actively want 
the model to be different, and most don't care about the differences 
between those two.

When the next draft of the document comes out, this can be rehashed 
again in the WG if there is a single specific Pace that gives a 
complete delta from that draft.

However, that Pace will not necessarily hold up us going to IETF last 
call, unless our AD wants it to. This kind of "does the model say A 
or B" discussion is quite appropriate in IETF last call, where folks 
who have very different model ideas might join in.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: PaceRepeatIdInDocument solution

[Graham]

On 20 Feb 2005, at 7:38 pm, Bob Wyman wrote:
would still be known. Note the originating server doesn't have to
store or keep track of anything.
	You propose timestamps, yet you oppose atom:modified -- which was
intended to provide precisely the timestamps you suggest. Or, is there
something I am missing? (atom:modified was entry-specific but you seem 
to be
suggesting a feed-global timestamp...)
No. As I said earlier, the only property of atom:modified we're 
interested in is:
  date(a)

Let's define an atom:version date element for each entry that has only 
that constraint. You can obviously still use a Last Modified Date to 
fulfil it. But what you can also do is have the originating server 
stamp each entry with the current date and time, and it still works. 
For example, if a client receives an old cached version, it will have 
an older date and can be discarded if an entry with a newer 
atom:version date is already known.

	Does your timestamp proposal imply that an entry which appeared in
multiple feeds would have a different timestamp in each feed it 
appeared?
Yes.
(Note: That would have the odd effect of tending to make error-prone 
copies
consistently appear to be the 'last modifications.' One tends to write 
to
the "main" feed first and then later to "category" feeds... Copies will
generally have timestamps later than the originals.)
We're talking serving static files, right? In this case the category 
feeds would still contain the old date they were generated until they 
were updated, preventing them from overwriting newer versions.

Graham

RE: PaceRepeatIdInDocument solution

[Bob Wyman]

Graham wrote:
> My idea would be that the originating server would simply stamp 
> entries with the current time during feed generation, so if they
> get mixed up in transit by third parties or caches the later version
> would still be known. Note the originating server doesn't have to
> store or keep track of anything.
You propose timestamps, yet you oppose atom:modified -- which was
intended to provide precisely the timestamps you suggest. Or, is there
something I am missing? (atom:modified was entry-specific but you seem to be
suggesting a feed-global timestamp...)
Is the problem in your comment that "the originating server doesn't
have to store or keep track of anything"? Does this imply that your
timestamp is really just the atom:updated of the feed and would change every
time that the feed was updated? If this is the case, should we reword the
definition of atom:updated to say that when it is used as feed metadata, it
MUST be updated every time the feed is changed in ANY way? Should the
"significant change" words only apply to atom:updated in entries? (Note:
Since the feed's atom:updated is an element of Head, this implies that if
HeadInEntry stands, the feed's atom:updated would or could be "in the
entry.")
If your timestamp is really the same as the feed's atom:updated,
then what is the impact of your proposal on signatures? Would all individual
entries in a feed need to be re-signed every time any change was made to the
feed such as inserting a new entry? Would this be the case even if the
change did not otherwise modify the signed entry? 
Does your timestamp proposal imply that an entry which appeared in
multiple feeds would have a different timestamp in each feed it appeared?
(Note: That would have the odd effect of tending to make error-prone copies
consistently appear to be the 'last modifications.' One tends to write to
the "main" feed first and then later to "category" feeds... Copies will
generally have timestamps later than the originals.)

> Generating a last modification date according to someone else's
> idea of modification is not pretty.
Yes! This is the problem that an intermediary in the channel faces.
The intermediary (a proxy, retrospective search engine, prospective matching
engine, etc.) needs to know which entry is the most recent modification.
However, Atom provides no mechanism by which the last modification can be
identified without heuristics. (atom:updated only tells you the time of the
last "significant" modification but that leaves you unable to determine
which of various alternative "insignificant" modifications should be passed
on by the intermediary.
Without help from the Atom format, the best an intermediary can do
is keep track of "date_entry_was_found". However, this can cause problems
since entries can exist in multiple feeds. Thus, the order in which the
feeds are read can cause old entries to over-write newer ones.
 
bob wyman

Re: PaceRepeatIdInDocument solution

[Graham]

On 20 Feb 2005, at 4:30 pm, Eric Scheid wrote:
if this use case was on the table back then, and you were to consider 
the
question in that light, where would you stand?
I like the model where the feed content is approximately "The current 
version of the latest entries". I don't think anything else makes much 
sense, least of all "Various states past and present of various entries 
(some assembly required)".

heh -- one way to then generate to fit your requirements would be
My idea would be that the originating server would simply stamp entries 
with the current time during feed generation, so if they get mixed up 
in transit by third parties or caches the later version would still be 
known. Note the originating server doesn't have to store or keep track 
of anything.

As to defining "modification" ... I was writing spec text which 
attempted
just that ... I was working towards the idea that any changes in 
values of
atom:entry elements, other than serialisation (including character 
encoding
and element order), and ignoring any changes in referenced resources.
But that gets complicated to generate cleanly. When you edit your feed 
template you need to do something like:

  if (entry modification date > date template was edited)
 print date template was edited
  else
 print entry modification date
Generating a last modification date according to someone else's idea of 
modification is not pretty.

My apologies: I was making an analogy, not providing an example. As 
such,
ignore the specifics of the analogy. I should have just written "Spec 
FOO is
silent on X, therefore X is verboten". Which is a nonsense position.
I wouldn't define the phrase "universally unique" as Atom being silent. 
It is massively open to interpretation since the literal meaning is 
nonsense, and I suppose conveying no useful information could be 
interpreted as silence.

Graham

Re: PaceRepeatIdInDocument solution

[Walter Underwood]

About logical clocks in atom:modified:

--On February 21, 2005 3:30:13 AM +1100 Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> Semantically, it would work ... for comparing two instances of one entry. It
> wouldn't work for establishing if an entry was modified before or after
> [some event moment] (eg. close of the stock exchange).

Establishing sequences of events is rather tricky. See Leslie Lamport's
"Time, Clocks, and the Ordering of Events in Distributed Systems" for how
to do it with logical clocks. The core part of the paper is short, maybe
five pages, and definitely worth reading if you care about this stuff.

 

Synchronized clocks make this simpler. If Atom depends on comparing timestamps
from different servers, then synchronized clocks are a SHOULD. See the text in
PaceCaching for an example.

Synchronized clocks are already a SHOULD for HTTP.

wunder
--
Walter Underwood
Principal Architect, Verity

Re: PaceRepeatIdInDocument solution

[Henry Story]

On 20 Feb 2005, at 17:10, Graham wrote:
On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same 
atom:id.
Which part of "universally unique" didn't you understand?
Ok, I see so you interpret the "universally unique" in
[[
An Identity construct is an element whose content  conveys a permanent, 
universally unique identifier for  the construct's parent. Its content 
MUST be a URI, as  defined by [RFC3986]. Note that  the definition of 
"URI" excludes relative references.
]]

to mean that there can only be one entry in a feed with the same id, and
presumably across all feeds, or else why use the word "universally" and
not "feedally"?
Why could we not then allow another id construct, call it "entryId" that
would be what all entries that are just editorial changes of one another
have in common?
This would be something like:

...

tag:bblfish.net/entry1/version1
tag:bblfish.net/entry1/
Atom Robots Run Amok
...


tag:bblfish.net/entry1/version2
tag:bblfish.net/entry1/
Atom-Powered Robots Run Amok
...



As you can see in the above feed there are no two entries with
the same id. Yet there are two entries with the same "entryid".
Would the above be an ok feed for you, or are there some other
reasons why a entryid node would be illegal?
	It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of aggregated feeds.
Aggregated feed generators are supposed to maintain atom:id unchanged 
when
they copy entries into an aggregate feed.
This is a fair point. I concede that multiple versions of entries with 
the same id is acceptable if and only if they have different feed ids 
in their head-in-entry, since essentially then they aren't in the same 
feed.
So should we replace "universally unique" above with "unique in a feed" 
then?

Graham

Re: PaceRepeatIdInDocument solution

[Eric Scheid]

On 20/2/05 4:34 PM, "Graham" <[EMAIL PROTECTED]> wrote:

> That's not what I meant. I opposed atom:modified because this use case
> wasn't on the table then. I oppose multiple ids partly because we don't
> have atom:modified. You can't have one without the other.

if this use case was on the table back then, and you were to consider the
question in that light, where would you stand?

(actually, we could have atom:modified while still outlawing multiple id's,
but you are right that atom:modified is required to disambiguate if multiple
id's are allowed.)

> My real problem with atom:modified is that it's unnecessarily tied to
> the Last Modification Date semantic, when it would work just as well
> for this purpose if it weren't. We just need a date with the constraint
> "date(a) b". This would make it easier to generate in various scenarios, and
> sidestep the problem of defining what a "modification" is.

heh -- one way to then generate to fit your requirements would be

atom:modified := atom:published + sequential-number

that is, increment the atom:modified by one second for every version.

Semantically, it would work ... for comparing two instances of one entry. It
wouldn't work for establishing if an entry was modified before or after
[some event moment] (eg. close of the stock exchange).

As to defining "modification" ... I was writing spec text which attempted
just that ... I was working towards the idea that any changes in values of
atom:entry elements, other than serialisation (including character encoding
and element order), and ignoring any changes in referenced resources.

>> Nonsense. That's like arguing that http agents should only support those
>> mime-types which were already defined oh so many years ago. No software
>> currently exists that can possibly be expecting "application/foo", but that
>> doesn't mean "application/foo" is an illegal mime-type.
>> 
> No, since the HTTP spec says that any mime type is possible, whereas the Atom
> spec says ids are "universally unique". If it's wrong to then think you won't
> find the same id twice in the same document, the spec needs to say so.

My apologies: I was making an analogy, not providing an example. As such,
ignore the specifics of the analogy. I should have just written "Spec FOO is
silent on X, therefore X is verboten". Which is a nonsense position.

e.

Re: PaceRepeatIdInDocument solution

[Graham]

On 20 Feb 2005, at 4:07 am, Bob Wyman wrote:
PubSub regularly produces feeds with multiple instances of the same 
atom:id.
Which part of "universally unique" didn't you understand?
	It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of aggregated feeds.
Aggregated feed generators are supposed to maintain atom:id unchanged 
when
they copy entries into an aggregate feed.
This is a fair point. I concede that multiple versions of entries with 
the same id is acceptable if and only if they have different feed ids 
in their head-in-entry, since essentially then they aren't in the same 
feed.

Graham

Re: PaceRepeatIdInDocument solution

[Sam Ruby]

Bob Wyman wrote:
	Given that history shows that publishing repeated ids has never
bothered anyone enough to cause them to complain, we should permit this
benign practice to continue. 
I have exactly the opposite experience.  I have people who have thanked 
me for noticing that they have repeated ids as it indicated an error in 
their software.

- Sam Ruby

Managing entries/entry state [was PaceRepeatIdInDocument solution]

[Bill de hÓra]

Chairs/Editors,
- I think that this discussion (repeat ids) is architecturally 
significant in terms of how Atom layers onto the Web and is best taken 
forward under feed state,

- Feed state discussion ought to deal explicitly with entry state, as 
that's the more difficult case.


Graham wrote:

No, I'm talking about storing the entries retrieved from different uris 
in the same local record and letting them overwrite each other. A really 
smart aggregator would inform the user that they got different versions 
from each place, and let them see both.

> On 20 Feb 2005, at 4:38 am, Eric Scheid wrote:
None. That's why it should be explicitly barred, since no software is
expecting it.

Nonsense. That's like arguing that http agents should only support those
mime-types which were already defined oh so many years ago. No software
currently exists that can possibly be expecting "application/foo", but 
that
doesn't mean "application/foo" is an illegal mime-type.

Graham, Eric,
My thinking goes like this,
 - Is there a difference between an entry and the chunk of XML you see 
in a feed?

- If there is, it will be in the same way there is a difference between 
a resource and a representation in web architecture.

- If you *don't* think a difference exists between an entry and the 
chunk of XML you see in a feed, there may be things you can't sensibly 
say [1]. For example if we disallow multiple appearance of an id in one 
feed we might as well disallow multiple appearance of an id across all 
feeds, for consistency. That, or document our spec's private definition 
of the word "unique".

- If you *do* think a difference exists between an entry and the chunk 
of XML you see in a feed, there may be some practical limitations. For 
example we will want to ask what's the difference operationally between 
two Entries that have been assigned the same id and the appearance of 
two entries with the same in an Atom document that represent the Entry 
at different states? What's the test that distinguishes between those 
two cases?

- That we can start sending multiple representations of a resource each 
marked as so inside another single representation I suspect extends web 
architecture. I looked and didn't see any support for this idea in AWWW. 
 Whether it's tunneling, abuse, or a new application layer I don't know.

- Maybe the WebDAV folks have been through this. HTTP has no obvious use 
cases or support for serving up resource state in one entity body rather 
than as a stream of entities.

My opinion is that keeping XML representations of entries distinct from 
entries affords the most flexibility and maximises internal consistency 
for the kind of use cases feeds support [2]. It will be an arbitrary 
limitation of language if Atom can't deliver entries with the same id in 
the same feed - I don't believe that limitation will be respected in 
practice. It also means we're (possibly) formalizing something for the 
Web that hasn't been done before.

cheers
Bill
[1] I emphasise 'sensibly say' here rather than 'sensibly do'. Just 
because or spec can't say something doesn't mean people won't try to do 
it if they think they need to.

[2] I spend a lot of time dealing with identity issues in my job. I've 
come to believe that neither unique ids or content based identity or a 
combination of both can eliminate all ambiguities. Sometimes you have to 
guess whether two things are the same no matter what model you're 
working with.

Re: PaceRepeatIdInDocument solution

[Graham]

On 20 Feb 2005, at 4:38 am, Eric Scheid wrote:
You opposed it because you couldn't foresee any use case for it, and 
now you
have a use case for it but you say that that use case should be banned
because you opposed atom:modified.
That's not what I meant. I opposed atom:modified because this use case 
wasn't on the table then. I oppose multiple ids partly because we don't 
have atom:modified. You can't have one without the other.

My real problem with atom:modified is that it's unnecessarily tied to 
the Last Modification Date semantic, when it would work just as well 
for this purpose if it weren't. We just need a date with the constraint 
"date(a)

Naïve or smart? I subscribe to one feed which is the top headlines for 
that
site, and I also subscribe to all headlines for one category at that 
site.
The "naïve" thing to do there would be to not conflate entries with
identical id's.
No, I'm talking about storing the entries retrieved from different uris 
in the same local record and letting them overwrite each other. A 
really smart aggregator would inform the user that they got different 
versions from each place, and let them see both.

None. That's why it should be explicitly barred, since no software is
expecting it.
Nonsense. That's like arguing that http agents should only support 
those
mime-types which were already defined oh so many years ago. No software
currently exists that can possibly be expecting "application/foo", but 
that
doesn't mean "application/foo" is an illegal mime-type.
No, since the HTTP spec says that any mime type is possible, whereas 
the Atom spec says ids are "universally unique". If it's wrong to then 
think you won't find the same id twice in the same document, the spec 
needs to say so.

Graham

Re: PaceRepeatIdInDocument solution

[Eric Scheid]

On 20/2/05 1:47 PM, "Graham" <[EMAIL PROTECTED]> wrote:

> On 20 Feb 2005, at 1:27 am, Eric Scheid wrote:
> 
>> hmmm ... looking back in the archives I see you were opposed to
>> atom:modified, you couldn't see any use case where you would want the entry
>> instances to clearly indicate which is more recent. Hashes won't help you
>> here.
>> 
> Yes, if you want multiple versions you need atom:modified. I oppose both.
> 
atom:modified also helps in distinguishing multiple instances found in
separate feed documents.

You oppose atom:modified, and yet you insist on kludging a hack for
identifying which of two entries is the most recent. A hack which isn't even
mentioned in the spec, so gawd help software developers all arriving at the
same hacky solution to the problem.

You opposed it because you couldn't foresee any use case for it, and now you
have a use case for it but you say that that use case should be banned
because you opposed atom:modified.

I forget: is this the circular reasoning logical fallacy, or the begging the
question fallacy?

>> A paradigm that fails completely once a reader starts traversing @rel="prev"
>> 
> Not if the url in the prev is properly thought through; ie instead of asking
> for "page 2" the uri query asks for "entried before n", where n is the oldest
> entry number in the page before.

Where are these special semantics codified into a specification?

Also, define "oldest". Is this the one with the oldest atom:updated, even
though you earlier (and rightly) dissed that because it was "that the author
considered significant". Or is oldest defined by atom:published, which as
you might recall is an *optional* element for atom:entry.

Also, define "number" in "entry number". Entries are not numbered, they have
id's, and while it's often easy to use an incrementing serial that is not
always the case. 

> Anyway, rel="prev" doesn't exist last time I checked.

This does: @rel="http://www.example.org/atom/link-rels#prev";, and that's a
valid value for the @rel attribute. There is also no language in the spec
that prevents someone registering "prev" in the Registry of Link Relations.



So you might as well assume it does exist.

>> or they have a planet aggregator in their subscriptions which has fallen
>> behind due to ping lags.
>> 
> Are there really aggregators naïve enough to take an entry with the same id
> from one feed and paste over the last retrieved entry from another?
> 
Naïve or smart? I subscribe to one feed which is the top headlines for that
site, and I also subscribe to all headlines for one category at that site.
The "naïve" thing to do there would be to not conflate entries with
identical id's.

Another use case: I subscribe to a feed from the publisher's website, but
later he sets up a link at feedburner.com or similar. The naïve thing would
be to assume that all the entries from feedburner.com are completely
different from those retrieved from example.com, despite having the same
id's.

> There are far more problems with that before you start worrying about what is
> the latest entry.
> 
You forget: I determine what entries I subscribe to, as you do for yourself.
If a bad actor starts screwing with id's then I can also unsubscribe.

So, leaving aside hand waving scare-mongering statements like "far more
problems", just what problems are there Graham?

>> "the newest version" is something which should be publisher controlled, not
>> left to the variable circumstances of protocol happenstance and idiosyncratic
>> personal subscription lists.
>> 
> or "picking randomly", as you suggested not 2 emails ago.
> 
Glad you agree with me there.

We wouldn't need to pick randomly if we had atom:modified.

>> OK, lets look at feed readers that don't then [etc]
>> 
> This is where Eric dictates how other people's feed readers should work to fit
> the flaws in his preferred proposition.
> 
A gross sophistry on your part. If you don't want to argue the merits and
prefer ad hominem attacks, then there really isn't much point continuing.

>> [1] do you know of any publishing software which currently emits feeds with
>> multiple instances of entries? I can't think of any.
>> 
> None. That's why it should be explicitly barred, since no software is
> expecting it.

Nonsense. That's like arguing that http agents should only support those
mime-types which were already defined oh so many years ago. No software
currently exists that can possibly be expecting "application/foo", but that
doesn't mean "application/foo" is an illegal mime-type.

e.

RE: PaceRepeatIdInDocument solution

[Bob Wyman]

Graham wrote:
>> [1] do you know of any publishing software which currently emits
>> feeds with multiple instances of entries? I can't think of any.
> None. That's why it should be explicitly barred, since no software
> is expecting it.
PubSub regularly produces feeds with multiple instances of the same
atom:id. No one has every complained about this to us.
Given that history shows that publishing repeated ids has never
bothered anyone enough to cause them to complain, we should permit this
benign practice to continue. 
It is particularly important to avoid prohibiting this benign
practice since it is so important to generators of aggregated feeds.
Aggregated feed generators are supposed to maintain atom:id unchanged when
they copy entries into an aggregate feed. However, the Atom format doesn't
provide rigorous guarantees that atom:id's will be unique across feeds.
Thus, aggregated feed publishers are left with the choice of 1) Trusting
feed publishers or 2) Assigning new atom:id's to all entries published. The
first option will inevitably result in repeated ids and the second results
in massive amounts of work, difficulties in duplicate detection, violation
of the "maintain atom:id" rule, etc.
Forbidding repeated ids causes damage. History shows, however, that
allowing repeated ids is benign.

bob wyman

Re: PaceRepeatIdInDocument solution

[Graham]

On 20 Feb 2005, at 1:27 am, Eric Scheid wrote:
hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the 
entry
instances to clearly indicate which is more recent. Hashes won't help 
you
here.
Yes, if you want multiple versions you need atom:modified. I oppose 
both.

A paradigm that fails completely once a reader starts traversing
@rel="prev"
Not if the url in the prev is properly thought through; ie instead of 
asking for "page 2" the uri query asks for "entried before n", where n 
is the oldest entry number in the page before.

Anyway, rel="prev" doesn't exist last time I checked.
or they have a planet aggregator in their subscriptions which
has fallen behind due to ping lags.
Are there really aggregators naïve enough to take an entry with the 
same id from one feed and paste over the last retrieved entry from 
another? There are far more problems with that before you start 
worrying about what is the latest entry.

"the newest version" is something which should be publisher 
controlled, not
left to the variable circumstances of protocol happenstance and
idiosyncratic personal subscription lists.
or "picking randomly", as you suggested not 2 emails ago.
OK, lets look at feed readers that don't then [etc]
This is where Eric dictates how other people's feed readers should work 
to fit the flaws in his preferred proposition.

[1] do you know of any publishing software which currently emits feeds 
with
multiple instances of entries? I can't think of any.
None. That's why it should be explicitly barred, since no software is 
expecting it.

Graham

Re: PaceRepeatIdInDocument solution

[Eric Scheid]

On 20/2/05 10:40 AM, "Graham" <[EMAIL PROTECTED]> wrote:

>> If two instances with the same atom:id have the same atom:updated, then there
>> is no significant difference between the two, so go with a random choice
>> 
> *that the author considered significant*. If you've told the user they're
> getting the latest version, and they see something else, that doesn't fit my
> definition of working correctly.
> 

Like I said, lobby for atom:modified.

hmmm ... looking back in the archives I see you were opposed to
atom:modified, you couldn't see any use case where you would want the entry
instances to clearly indicate which is more recent. Hashes won't help you
here.

Is this where I say "told you so"? ;-)

> A paradigm where the instance in the feed is always the newest version works
> much much better.
> 

A paradigm that fails completely once a reader starts traversing
@rel="prev", or they have a planet aggregator in their subscriptions which
has fallen behind due to ping lags.

"the newest version" is something which should be publisher controlled, not
left to the variable circumstances of protocol happenstance and
idiosyncratic personal subscription lists.

>> For feed readers that already support entry persistence and entry replacement
>> when an entry is updated from one document to the next, why is this an order
>> of magnitude more difficult to do in the one document?
>> 
> I was talking about feed readers that don't.

OK, lets look at feed readers that don't then ... first off, generally
speaking, you're unlikely to find a feed instance which does contain
multiple entries with the same id, and if you did it would be because that
is how the publisher wants it. The publisher wants both instances available
for reading, who are you to conflate the two? If there is some broken [1]
publishing software out there then readers will complain to the publisher
(if they complain to you, say "that's how the publisher wants it").

Secondly, there is that use case where an archive of all versions of an
entry is provided in a feed. This is provided so users can see all previous
versions of the entry ... is it so bad then that a naïve feed reader would
then display all versions of that entry?

e.

[1] do you know of any publishing software which currently emits feeds with
multiple instances of entries? I can't think of any.

Re: PaceRepeatIdInDocument solution

[Henry Story]

On 19 Feb 2005, at 16:46, Graham wrote:
On 19 Feb 2005, at 11:23 am, Henry Story wrote:
Let me make my point even clearer. If something is "fundamentally 
incompatible",
then it should be *dead-easy* to prove or reveal this incompatibility.
i) Syndication documents shouldn't ever contain multiple versions of 
the same entry*.
ii) Archive documents apparently need to be able to contain multiple 
versions of the same entry.

* for the simple reason that it makes them an order of magnitude 
harder to process and display correctly (and often impossible to 
display correctly, since it won't always be clear which is the latest 
version).
I don't accept that it makes it an order of magnitude harder to process 
these
documents, or if it is an order of magnitude harder, its an order of 
magnitude
larger than an infinitesimal amount, which is still an infinitesimal 
amount.
I am writing such a tool, so I think I have some grasp on the subject.

But accepting for the sake of argument that you are right, you need 
compare the difficulty of writing a feed reader with the difficulty of 
writing a feed
itself. Not allowing duplicate versions of an entry in a feed just 
pushes the
complexity of writing the feed from the feed reader to the feed writer:
now the feed writer has to contain the logic to make sure than no 
duplicates
appear in the feed.  Instead of the feed writer just being able to 
paste the
new entry to the end of the feed, it has to parse the whole feed 
document
and make sure it contains no duplicates.

Since I can see very good reasons to make life easier for the feed 
writer, in the
same way as one has tried to keep html simple for the common html 
writer, I
think your argument may in fact turn out to be a good supporting 
argument for
allowing multiple versions of an entry in the same feed document.

Your wittering on about conceptual models doesn't make you better than 
us.
I never pretended it does make me better.
I have been exploring tools such as rdf, as I believe that they can 
bring a
lot of clarity to debates such as this one. Just as engineers don't 
hesitate
to use mathematics to help them in their tasks, so I think using logical
analysis should help us here. I hope that as I understand these tools 
better
I will be able to explain the insights these disciplines bring in 
plainer
english.

In the mean time I have a lot of respect for Tim Berners Lee, and
I try my best to understand the direction he is going in, the tools he
is developing and the insights these lead to.
Henry Story
http://bblfish.net/
Graham

Re: PaceRepeatIdInDocument solution

[Graham]

On 19 Feb 2005, at 11:06 pm, Eric Scheid wrote:
If two instances with the same atom:id have the same atom:updated, 
then there is no significant difference between the two, so go with a 
random choice
*that the author considered significant*. If you've told the use 
they're getting the latest version, and they see something else, that 
doesn't fit my definition of working correctly. A paradigm where the 
instance in the feed is always the newest version works much much 
better.

For feed readers that already support entry persistence and entry
replacement when an entry is updated from one document to the next, 
why is
this an order of magnitude more difficult to do in the one document?
I was talking about feed readers that don't.
And even those that do, you now need to look for duplicates within the 
feed instead of just comparing the new set to the old set. ie Instead 
of removing duplicates that exist between set A and set B, I now also 
have to look within set A as well. You seem to have suggested earlier 
that entries be added to the store one by one. This is not possible in 
Shrook because of the various layers of idiot proofing.

Graham

Re: PaceRepeatIdInDocument solution

[Eric Scheid]

On 20/2/05 2:46 AM, "Graham" <[EMAIL PROTECTED]> wrote:

> i) Syndication documents shouldn't ever contain multiple versions of
> the same entry*.
> 
> * for the simple reason that it makes them an order of magnitude harder
> to process and display correctly (and often impossible to display
> correctly, since it won't always be clear which is the latest version).

Think of a feed as a stream of entry instances (not hard to do), and process
accordingly. The same thing with a feed document. Whether you read from the
top of the document to the bottom, or vice versa, shouldn't matter - you can
identify the more recent entry by atom:updated. If two instances with the
same atom:id have the same atom:updated, then there is no significant
difference between the two, so go with a random choice (that's not hard
either) (and lobby for atom:modified while you're at it).

For feed readers that already support entry persistence and entry
replacement when an entry is updated from one document to the next, why is
this an order of magnitude more difficult to do in the one document?

e.

Re: PaceRepeatIdInDocument solution

[Roger B.]

> i) Syndication documents shouldn't ever contain multiple versions of
> the same entry*.

Graham: +1.

> ii) Archive documents apparently need to be able to contain multiple
> versions of the same entry.

I don't even buy that much, personally.

--
Roger Benningfield

Re: PaceRepeatIdInDocument solution

[Graham]

On 19 Feb 2005, at 11:23 am, Henry Story wrote:
Let me make my point even clearer. If something is "fundamentally 
incompatible",
then it should be *dead-easy* to prove or reveal this incompatibility.
i) Syndication documents shouldn't ever contain multiple versions of 
the same entry*.
ii) Archive documents apparently need to be able to contain multiple 
versions of the same entry.

* for the simple reason that it makes them an order of magnitude harder 
to process and display correctly (and often impossible to display 
correctly, since it won't always be clear which is the latest version).

Your wittering on about conceptual models doesn't make you better than 
us.

Graham

Re: PaceRepeatIdInDocument solution

[Henry Story]

On 18 Feb 2005, at 23:55, Graham wrote:
Allowing more than one version of the same entry in a syndication 
feed is unacceptable in itself, which is fundamentally incompatible 
with archive feeds, no matter what the conceptual definition of id 
is.

Graham
Let me make my point even clearer. If something is "fundamentally 
incompatible",
then it should be *dead-easy* to prove or reveal this incompatibility.

So develop your thought a little, and you can only come out the winner.
Henry

Re: PaceRepeatIdInDocument solution

[Henry Story]

I think I can prove that the two versions are perfectly compatible and 
orthogonal. I can prove that logically there is no inconsistency, and
some empirical backing that this is feasible. But I am not alone. Bob
Wyman I believe has a lot more empirical support.

You on the other hand, as usual I notice, have absolutely no argument to
defend your case.
Henry Story
On 18 Feb 2005, at 23:55, Graham wrote:
Allowing more than one version of the same entry in a syndication feed 
is unacceptable in itself, which is fundamentally incompatible with 
archive feeds, no matter what the conceptual definition of id is.

Graham

Re: PaceRepeatIdInDocument solution

[Graham]

Allowing more than one version of the same entry in a syndication feed 
is unacceptable in itself, which is fundamentally incompatible with 
archive feeds, no matter what the conceptual definition of id is.

Graham

Re: PaceRepeatIdInDocument solution

[Henry Story]

I was not able to go and do the exercise I wanted to do, so here is a
more carefully worded version

The id construct in atom is ambiguous between two meanings. Since the
two meanings are orthogonal and not incompatible when properly 
distinguished,
the best solution is to distinguish them and allow both.

I would replace the following text in the spec:

4.5 The "atom:id" Element
The "atom:id" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed.


with

4.5 The "atom:versionId" Element
The "atom:versionId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed version. 
There can only be
one entry  with the same versionId per feed document. There can be only 
one feed
document with the same versionId.

4.6 The "atom:id" Element
The "atom:entryId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can be more
than one entry per feed document with the same id. And there can be 
multiple
feed documents with the same id.


Note:
atom:versionId is what I have called elsewhere the equivalence id 
relation
atom:entryId is what I have called the functional id relation

The above will allow the feed format to also be used as an archive 
format
if needed.

It clearly distinguishes the two types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate 
one
way and other Paces tried to disambiguate the other way.

As such it correctly resolves an ambiguity by allowing both options.
Henry Story
Ps. text above written quickly cause I have to go do some exercise.

PaceRepeatIdInDocument solution

[Henry Story]

The PaceRepeatIdInDocument tries to set the constraints in the
Identity construct whereas the constraint should have gone on the
individual elements.
Instead I would replace the following in the spec:

4.5 The "atom:id" Element
The "atom:id" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed.


with

4.5 The "atom:versionId" Element
The "atom:versionId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can only be one entry
per feed document with the same id.

4.6 The "atom:entryId" Element
The "atom:entryId" element is an Identity construct that  conveys a 
permanent, universally unique identifier for an  entry or feed. There 
can be more
than one entry per feed document with the same id.


Note:
atom:versionId is the what I have called elsewhere the equivalence id 
relation
atom:entryId is what I have called the functional id relation

The above will allow the feed format to also be used as an archive 
format
if needed.

It clearly distinguishes the two types of ids that were hidden
in the ambiguous text that PaceRepeatIdInDocument tried to disambiguate 
one
way and others tried to disambiguate the other way.

As such it correctly resolves an ambiguity by allowing both options.
Henry Story
Ps. text above written quickly cause I have to go do some exercise.