Subject: Re: atom:id, urn:issn, feed archiving, and uniqueness

From: Aristotle Pagaltzis <[email-masked]>
Date: Fri, 1 Feb 2008 15:41:45 +0100

* Daniel Aleksandersen <[email-masked]> [2008-02-01 05:15]:
> It is not globally unique on a per my feed basis; but it is
> globally unique on a per…me…basis.

Put the ISSN into a tag: URI instead of using the urn:issn:
scheme.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: Antone Roundy <[email-masked]>
Date: Fri, 01 Feb 2008 10:37:56 -0600

Daniel Aleksandersen wrote:
> I atom:id-entify the main feed using an ISSN. (See below for example.) 
> This number is unique to my publication and I use it one time per feed.
> 
> <feed … >
>   <id>urn:issn:1234-567X</id>
> </feed>
> 
> But when it comes to atom archiving, it gets a little trickier…. Should I 
> use the same ISSN as for my recent updates feed?

Yes, it would be appropriate to use it in both places.  The atom:id is 
associated with a single "feed" which isn't the same thing and a "feed 
document".  In other words, it's possible to have multiple documents 
that all represent the same "feed", and all of those documents would 
have the same atom:id.

In your case, you've got the recent updates document for the feed and 
the archive document(s) for the feed -- but both a tied to the same feed.

Antone

---

From: Daniel Aleksandersen <[email-masked]>
Date: Fri, 1 Feb 2008 20:18:52 +0100

> Put the ISSN into a tag: URI instead of using the urn:issn:

What good would that do?

To make a short process of this, can I append the archive date range at 
the end of the URN; as shown below:

<feed …>
  <fh:archive />
  <id>urn:issn:1234-567X#2008-01</id>
</feed>

That would create a unique, non‐changing ID for each of the individual 
feeds. I am not sure whether it violates the URN structure or the 
urn:issn specification though.
-- 
Daniel Aleksandersen <[email-masked]>

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 1 Feb 2008 11:55:44 -0800

Daniel wrote:
> Aristotle Pagaltzis wrote:

Does the identifier urn:issn:1234-567 uniquely identify a publication or an entry? It can't identify both, because then it is not a unique identifier.

> urn:issn:1234-567X#2008-01

What part of the publication with urn:issn:1234-567 does "2008-01" apply to? The first letter of the 2008th word, perhaps?

- Brian

---

From: Daniel Aleksandersen <[email-masked]>
Date: Fri, 1 Feb 2008 22:14:01 +0100

On 2008-02-01 20:55, Brian wrote:
> Does the identifier urn:issn:1234-567 uniquely identify a publication
> or an entry? It can't identify both, because then it is not a unique
> identifier.
>
> What part of the publication with urn:issn:1234-567 does "2008-01"
> apply to? The first letter of the 2008th word, perhaps?

No. I use this on the feed, and not entries.

<feed …>
  <id>urn:issn:1234-567X</id>
  <entry>
     <id>urn:uuid:example</id>
  </entry>
</feed>

The question was regarding archive feeds. Should these use the same ID as 
the main feed (issn), or should I append an archive date range as a 
second identifier (issn#date)?
-- 
Daniel Aleksandersen <[email-masked]>

---

From: Daniel Aleksandersen <[email-masked]>
Date: Sat, 2 Feb 2008 14:50:52 +0100

> apply to? The first letter of the 2008th word, perhaps?

It is supposed to identify the date. This is no standard! But the #part 
would solve my problem with keeping my ISSN in all feeds, but still have 
the ID be unique. I will try to explain with examples.

Here is /latest-entries.atom:
<feed …>
  <id>urn:issn:1234-567X</id>
  <entry>
    <id>urn:uuid:123456789X</id>
  </entry>
  <entry>
    <id>urn:uuid:X987654321</id>
  </entry>
</feed>

Here is /archive-2008-01.atom (January 2008):
<feed …xmlns:fh=…>
  <id>urn:issn:1234-567X#2008-01</id>
  <fh:archive/>
  <entry>
    <id>urn:uuid:123456789X</id>
  </entry>
  <entry>
    <id>urn:uuid:X987654321</id>
  </entry>
</feed>
-- 
Daniel Aleksandersen <[email-masked]>
Open Source Notebook - http://opensourcenotebook.com/

---

From: "David Nesting" <[email-masked]>
Date: Sat, 2 Feb 2008 09:06:47 -0800

On Feb 2, 2008 5:50 AM, Daniel Aleksandersen <
[email-masked]> wrote:

> the ID be unique.

Just be aware that applications aware of ISSN URNs may reject this URN as
invalid if it contains a fragment.  RFC3044 doesn't specify what a fragment
means in the context of an ISSN URN, and the URN spec explicitly cautions
against its use in URNs generally:

2.3.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

This means your Atom IDs (ISSN URNs) may only be readable to humans.  Using
a tag: URI as Aristotle suggested would let you use it however you wanted
(still with no computers understanding its semantics).  If your publication
has a canonical online presence, perhaps the atom:id could just be the
(permanent) URL to that issue online?

And this is all assuming you still feel you need distinct atom:ids for the
different versions of your feed.  I agree with Antone that there's no reason
they can't be the same, but do whatever makes the most sense for you.

Good luck.

David

---

From: Daniel Aleksandersen <[email-masked]>
Date: Sat, 2 Feb 2008 18:44:57 +0100

On 2008-02-02 18:06, David wrote:
>
> And this is all assuming you still feel you need distinct atom:ids for
> the different versions of your feed.  I agree with Antone that there's
> no reason they can't be the same, but do whatever makes the most sense
> for you.

So I should use the same ID for the feed, and the archive version of that 
feed?
-- 
Daniel Aleksandersen <[email-masked]>

---

From: Antone Roundy <[email-masked]>
Date: Sat, 02 Feb 2008 15:09:19 -0600

> So I should use the same ID for the feed, and the archive version of that 

That's what I would do, and for this reason: if someone finds both your 
lastest entries document and your archive document, they'll be able to 
recognize from the atom:id values that that the entries in each are 
copies of the same data.

It could be argued that since the entries' atom:id values are the same 
(assuming that's what you intended to do...which would be the correct 
thing to do since they're the same entries no matter what feed they get 
copied into), you should be able to recognize that the entries are the 
same from just those.  But the combination of the feed's atom:id and the 
entry's atom:id matching provides greater confidence that someone didn't 
accidentally duplicate someone else's ID.

Antone

---

From: Eric Scheid <[email-masked]>
Date: Sun, 03 Feb 2008 05:50:32 +1100

> <id>urn:issn:1234-567X#2008-01</id>

but aren't these just two different snapshots of the *same* feed?

as such, they should have the same feed id.

e.

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Mon, 4 Feb 2008 15:09:31 +0100

> > Put the ISSN into a tag: URI instead of using the urn:issn:

Tag URIs contain your domain, so they provide a globally unique
identifier, even if you’re using your ISSNs in them, which are
not by themselves globally unique.

* Daniel Aleksandersen <[email-masked]> [2008-02-01 22:30]:
> The question was regarding archive feeds. Should these use the
> same ID as the main feed (issn), or should I append an archive
> date range as a second identifier (issn#date)?

The entire point of atom:id is that entries are entities in their
own right and may appear in multiple different feeds; so the
atom:id for a particular entry should always be the same no
matter which feed that entry is in. If you use different IDs for
entries in your archive feed, you are effectively asserting that
the entries in the archive feed are not the same 

The feed might even be provided by a search engine such as
Icerocket, Bloglines or Google Blog Search; hence the requirement
for atom:id to be *globally* unique, not just unique within a
feed or even your domain. So urn:issn: URIs are not usable as
atom:id values. If you use them and some other publication uses
them in *their* feeds as well, then your entries won’t be
distinguishable by atom:id from the entries of that other
publication when a user goes to a feed search engine and gets
entries from both your and the other publication in the result
feed.

Another issue is that atom:id values are not supposed to be used
for any purpose other than identifying an entry, and so are not
supposed to be normalised in any way – only compared character-
by-character.

So in other words, don’t try to put anything meaningful in
atom:id – just make sure it is globally unique and never changes.

Hence why I said to use tag: URIs.

Regards,

---

From: Daniel Aleksandersen <[email-masked]>
Date: Mon, 4 Feb 2008 15:57:06 +0100

> Hence why I said to use tag: URIs.

Why does so many in this list fail to eralise that I am talking about the 
<feed> element’s <id> element? Not an <entry>’s? I see these messages 
were people think I am talking about entries all the time. That is wrong. 
I know that they should uniquely identify the entries in the <entry> 
element. But what about the the <feed> element?
-- 
Daniel Aleksandersen <[email-masked]>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Mon, 4 Feb 2008 22:08:42 +0100

* Daniel Aleksandersen <[email-masked]> [2008-02-04 16:10]:
> Why does so many in this list fail to eralise that I am talking
> about the <feed> element’s <id> element?

Ugh, sorry.

Well, the point about atom:id being globally unique continues to
apply in either case.

However, I’m not sure what the feed ID really identifies, nor can
I recall any compelling argument about its meaning, so I have no
idea when feeds should share an ID. (The fact that everyone
thought you were talking about entry IDs is a strong indicator
that no one has much use for feed IDs.)

In the context of Atompub it is somewhat clear: when two feeds
are views onto the same collection, they should probably have
the same ID. However, even then it is not necessarily clear
when a feed other than the collection feed is a view onto that
collection rather than a distinct entity that happens to draw
entries from the collection.

Regards,

---

From: Daniel Aleksandersen <[email-masked]>
Date: Mon, 4 Feb 2008 22:49:49 +0100

> that no one has much use for feed IDs.)

(It is an required child of the feed element. Everybody are required to 
use it.) I was surprised to not find any mentioning of the feed element’s 
id element it in urn:ietf:rfc:5005. It was one of the first things I 
wondered about when I learned of the specification.

> entries from the collection.

Then the question is whether the feed element’s id element identifies the 
feed or the collection [of entries]. As of now I am using the same id 
value for all the feeds. I will continue doing that until someone [in 
here] tells me otherwise.
-- 
Daniel Aleksandersen <[email-masked]>

---

From: Daniel Aleksandersen <[email-masked]>
Date: Mon, 4 Feb 2008 23:48:14 +0100

On 2008-02-04 23:06, you wrote:
> The Feed level atom:id is primarily useful as a logical group
> identifier.  For instance, suppose you have a collection of Atom feed
> documents representing a paged set.  Together, all of the entries
> comprise a single logical group commonly identified by the atom:feed's
> atom:id element.  If there was no atom:id element, there'd be no way of
> grouping entries from multiple feed documents into a single logical
> set.

Then why is this not written in any specifications?

---

From: Keith Fahlgren <[email-masked]>
Date: Mon, 04 Feb 2008 15:20:22 -0800

> Then why is this not written in any specifications?

I had always thought that intent was clear from the specification:

http://xml.resource.org/public/rfc/html/rfc4287.html#element.feed
"""
# atom:feed (The "atom:feed" Element) elements MUST contain exactly one atom:id """

http://xml.resource.org/public/rfc/html/rfc4287.html#element.id
"""4.2.6.  The "atom:id" Element

The "atom:id (The "atom:id" Element)" element conveys a permanent, universally
unique identifier for an entry or feed.

atomId = element atom:id {
   atomCommonAttributes,
   (atomUri)
}

Its content MUST be an IRI, as defined by [RFC3987] (Duerst, M. and M. Suignard,
“Internationalized Resource Identifiers (IRIs),” January 2005.). Note that the
definition of "IRI" excludes relative references. Though the IRI might use a
dereferencable scheme, Atom Processors MUST NOT assume it can be dereferenced.

When an Atom Document is relocated, migrated, syndicated, republished, exported,
or imported, the content of its atom:id (The "atom:id" Element) element MUST NOT
change. Put another way, an atom:id (The "atom:id" Element) element pertains to
all instantiations of a particular Atom entry or feed; revisions retain the same
content in their atom:id (The "atom:id" Element) elements. It is suggested that
the atom:id (The "atom:id" Element) element be stored along with the associated
resource.

The content of an atom:id (The "atom:id" Element) element MUST be created in a
way that assures uniqueness.

Because of the risk of confusion between IRIs that would be equivalent if they
were mapped to URIs and dereferenced, the following normalization strategy
SHOULD be applied when generating atom:id (The "atom:id" Element) elements:

    * Provide the scheme in lowercase characters.
    * Provide the host, if any, in lowercase characters.
    * Only perform percent-encoding where it is essential.
    * Use uppercase A through F characters when percent-encoding.
    * Prevent dot-segments from appearing in paths.
    * For schemes that define a default authority, use an empty authority if the
default is desired.
    * For schemes that define an empty path to be equivalent to a path of "/",
use "/".
    * For schemes that define a port, use an empty port if the default is desired.
    * Preserve empty fragment identifiers and queries.
    * Ensure that all components of the IRI are appropriately character
normalized, e.g., by using NFC or NFKC.
"""

HTH,
Keith

---

From: James M Snell <[email-masked]>
Date: Mon, 04 Feb 2008 14:06:08 -0800

grouping entries from multiple feed documents into a single logical set.

- James

---

From: "Kyle Marvin" <[email-masked]>
Date: Fri, 8 Feb 2008 10:47:31 -0600

On Feb 4, 2008 8:57 AM, Daniel Aleksandersen <
[email-masked]> wrote:

> <feed> element's <id> element? Not an <entry>'s? I see these messages

Hi Daniel,

FWIW, in the GData implementation of AtomPub we keep the feed-level atom:id
constant across all derived views of a collection/feed, and we support a
wide variety of query models (by-date, pagination, by label, etc).    Our
rationale was consistent with what others have said on this thread, that
it's beneficial because it can help to correlate that two different types of
queries have the same origin.   A related intepretation is the perspective
that queries/pagination don't create a new logical feed, which giving them a
unique id would imply.

We do, however, provide a feed-level self link relation href that contains
any query parameters, making it possible to retrieve the same (page,
date-range, ...) logical view of the feed again.  Thus, it "identifies a
resource equivalent to the containing element".

Cheers!

-- Kyle

---

From: Bill de hOra <[email-masked]>
Date: Fri, 08 Feb 2008 22:55:37 +0000

Daniel Aleksandersen wrote:
> Hi emailing list,
> 
> I think this is a very difficult question.
> 
> use the same ISSN as for my recent updates feed? The idea of ISSN is that 
> it should uniquely identify all issues of a serial publication. So it 
> would be appropriate to use it in the static feed archives as well as in 
> the continuously update feed. It is not globally unique on a per my feed 
> basis; but it is globally unique on a per…me…basis. If that made any 
> sense to anyone?

Yes, it made sense. Give the two feeds different ids.

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Fri, 08 Feb 2008 17:28:58 -0600

Bill de hOra wrote:
>> But when it comes to atom archiving, it gets a little trickier…. 
>> Should I use the same ISSN as for my recent updates feed? The idea of 
>> ISSN is that it should uniquely identify all issues of a serial 
>> publication. So it would be appropriate to use it in the static feed 
>> archives as well as in the continuously update feed. It is not 
>> globally unique on a per my feed basis; but it is globally unique on a 
>> per…me…basis. If that made any sense to anyone?
> 

But Bill, it's not two different feeds, it's two different views of the 
same feed -- an archive view, and a "latest entries" (a.k.a. "sliding 
window") view.  Thus the shared atom:id IS "globally unique on a per my 
feed basis", just not on a per feed DOCUMENT basis.

---

From: Bill de hOra <[email-masked]>
Date: Sat, 09 Feb 2008 14:02:57 +0000

Antone Roundy wrote:
>>> globally unique on a per my feed basis; but it is globally unique on 
>>> a per…me…basis. If that made any sense to anyone?
>>

What breaks if they have two different ids?

Put another way, why are two URLs required, but only one id? Are views 
(for any definition of "view") really a special case?

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Sat, 09 Feb 2008 10:03:19 -0600

Bill de hOra wrote:
>> But Bill, it's not two different feeds, it's two different views of 
>> the same feed -- an archive view, and a "latest entries" (a.k.a. 
>> "sliding window") view.  Thus the shared atom:id IS "globally unique 
>> on a per my feed basis", just not on a per feed DOCUMENT basis.
> 

Perhaps nothing "breaks", but it's just a little odd to have the same 
entries originating from two different feeds.  I presume neither 
document is going to use an atom:source element to show that they're not 
the originator of the entries, so it looks like you have two feeds and 
are erroneously using duplicate IDs for their entries.

 > (for any definition of "view") really a special case?

Two URLs: so that people can choose to get either the archive of or the 
live end of the feed.

One ID: because they're the same feed.

And by the way, is the archive document one monolithic document 
containing everything, or is it going to be split into a chain of 
archive documents?  If it's a chain, surely you wouldn't give each 
document in the chain it's own ID, right?

The reason to use the same ID in both cases is to show that they both 
represent the same feed -- that the one is the archive of the other.

---

From: Bill de hOra <[email-masked]>
Date: Sun, 10 Feb 2008 01:01:09 +0000

Antone Roundy wrote:
> entries originating from two different feeds.  

I don't find that odd; whereas I might find the same entry originating 
from two different authors odd.

> I presume neither 

If nothing breaks, how can it be an error?

> document in the chain it's own ID, right?

Why not?

> represent the same feed -- that the one is the archive of the other.

Try running Atom over XMPP. I think it might change how you view what a 
  feed 'is'. It did for me; I have a hard time explaining how, but it 
seems that feeds are a workaround for HTTP, which doesn't have 
containers or iterators.

cheers
Bill

---

From: Daniel Aleksandersen <[email-masked]>
Date: Mon, 11 Feb 2008 04:39:25 +0100

On 2008-02-10 02:01, you wrote:
> >>> "sliding window") view.  Thus the shared atom:id IS "globally
> >>> unique on a per my feed basis", just not on a per feed DOCUMENT
> >>> basis.
> >>

I am wondering what does break if they have the same ID?

> from two different authors odd.

I agree with Antone. It should be the same ID. If the point of the ID is 
to identify the source (collection, feed, whatever you want to call it) 
rather than the document (the feed file).

> > I presume neither
> > document is going to use an atom:source element to show that they're
> > not the originator of the entries, so it looks like you have two
> > feeds and are erroneously using duplicate IDs for their entries.
>

---

From: Eric Scheid <[email-masked]>
Date: Mon, 11 Feb 2008 19:11:09 +1100

> rather than the document (the feed file).

I'm pretty much in agreement here, although I would posit that there are
scenarios when the feed ID might be different, like re-syndication where
there is some collation and selection going on.

For example: one of my clients is a film industry news outlet and they have
their own blog and feeds, but they also re-syndicate selected articles from
the mainstream newspapers. In this scenario the one entry may appear in two
different feeds, each with their own feed id but retaining the entry ID of
course. 

Similarly if I gather together the "10 best blog posts about Atom" and
publish that as a feed then that feed would have a different ID from the
source feeds. Well, it'd have to, since if there are multiple source feeds I
can only have one feed ID in the document I publish.

The line gets blurry however when the re-syndicated feed only draws from one
source .. is this a filtered version of the source feed, or a new feed?

e.

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 11 Feb 2008 15:51:10 +0100

> source .. is this a filtered version of the source feed, or a new feed?

From RFC4287:
1. Introduction

   Atom is an XML-based document format that describes lists of related
   information known as "feeds".  Feeds are composed of a number of
   items, known as "entries", each with an extensible set of attached
   metadata.  For example, each entry has a title.

I understand it as "if the set/list of entries is different, this is
not the same feed", as is the case with a "filtered version".

I know this is subject to debate, as later on, the RFC reads:
   An Atom Feed Document is a representation of an Atom feed, including
   metadata about the feed, and some or all of the entries associated
   with it.  Its root is the atom:feed element.

Given that there's no mandatory way of getting "all of the entries
with" a feed, you cannot really compare two feed documents (or two
sets of feed documents) to determine whether they represent the same
feed or not.

My opinion however is that a "filtered version" of a feed is a new
feed; and Google should mint new atom:id's for GData's search result
feeds.

-- 
Thomas Broyer

---

From: Nikunj Mehta <[email-masked]>
Date: Mon, 11 Feb 2008 18:32:29 -0800

>> represent the same feed -- that the one is the archive of the other.
Not that there is an explicitly worded statement, but one would consider 
using the same ID in different archive documents of one feed. This is 
how the example in section 4 of RFC 5005 illustrates archive documents. 
In Antone's words, these form a chain of archive documents corresponding 
to a large feed.

However, neither RFC 5005 nor RFC 5023 specifically state a requirement 
on the id of the partial lists of a collection, or the pages of a feed. 
In the absence of such a requirement, there cannot be any expectation 
that they are all identified identically. Given this, it seems perfectly 
logical to treat the id of a feed as a container aka feed document 
identifier, and that different containers aka feed documents (even when 
used in concert to represent a single feed) are better off using their 
own identifiers.

Also, given that there is no requirement that the various physical views 
of a feed -- pages, archives, subsets derived through queries, etc -- 
carry a single id, the atom:id element inside a feed loses any meaning 
beyond a "container identifier". Applying this I conclude that there is 
no requirement that the GData query feed have the same atom:id as the 
one present in the collection feed.
> Try running Atom over XMPP. I think it might change how you view what 
> a  feed 'is'. It did for me; I have a hard time explaining how, but it 
Bill seems to suggest that seen in the context of XMPP, a feed document 
as a container is equivalent to a stream. Therefore, the stream 
identifier, seen as the session key, does not have any permanence. Not 
only that, there cannot be correlation between the identifiers of 
different streams.

However, feeds are used for a one-to-many communication whereas XMPP 
streams are used for one-to-one communication, IMHO. It helps to have 
the same id be used for different feed documents, even those obtained at 
different times from the same URL.

    * Isn't this how feed aggregators seem to track the evolution of a
      feed's contents over time and to present a historical view of that
      feed?
    * If not, is there a standards-based means of tracking this evolution?

It would help if the authors of RFC 5005 or 5023 can clarify if there is 
a reason why these specs do not deal with the issue of atom:id in pages, 
archive documents, and partial lists.

Nikunj

---

From: Daniel Aleksandersen <[email-masked]>
Date: Tue, 12 Feb 2008 12:26:58 +0100

On 2008-02-12 03:32, you wrote:
> >> The reason to use the same ID in both cases is to show that they
> >> both represent the same feed -- that the one is the archive of the
> >> other.
>
> Not that there is an explicitly worded statement, but one would
> consider using the same ID in different archive documents of one feed.
> This is how the example in section 4 of RFC 5005 illustrates archive
> documents. In Antone's words, these form a chain of archive documents
> corresponding to a large feed.
>
> that they are all identified identically. Given this, it seems
> perfectly logical to treat the id of a feed as a container aka feed
> document identifier, and that different containers aka feed documents
> (even when used in concert to represent a single feed) are better off
> using their own identifiers.
>
> Also, given that there is no requirement that the various physical
> views of a feed -- pages, archives, subsets derived through queries,
> etc -- carry a single id, the atom:id element inside a feed loses any
> meaning beyond a "container identifier". Applying this I conclude that
> there is no requirement that the GData query feed have the same atom:id
> as the one present in the collection feed.
>
> > a  feed 'is'. It did for me; I have a hard time explaining how, but
> > it seems that feeds are a workaround for HTTP, which doesn't have
> > containers or iterators.
>
> the same id be used for different feed documents, even those obtained
> at different times from the same URL.
>
>       feed's contents over time and to present a historical view of
> that feed?
> It would help if the authors of RFC 5005 or 5023 can clarify if there
> is a reason why these specs do not deal with the issue of atom:id in
> pages, archive documents, and partial lists.

The very first question that came to my mind after reading RFC 5005 
was ‘but what about the atom:id?’ I thought it may have been overlooked 
in the specifications.
-- 
Daniel Aleksandersen <[email-masked]>
http://www.opensourcenotebook.com/

---

From: "Kyle Marvin" <[email-masked]>
Date: Tue, 12 Feb 2008 08:58:37 -0600

On Feb 11, 2008 8:32 PM, Nikunj Mehta <[email-masked]> wrote:

> that they are all identified identically.

I can agree with the "cannot be any expectation" part of this, given the
general vagueness of specification around feed-level atom:id;  however, I'd
observe that "not required to use the same atom:id"  due to lack of clarity
is distinctly different from "thus should not use the same atom:id".

> Given this, it seems perfectly

I'm not necessarily following the logic.   See above statements.   A use
case for the benefits of sharing an atom:id (being able to tell that all
feed documents derive from the same source collection) has been stated, and
I suspect was the motivation for the sample usage in RFC5005.    If this
benefit is perceived to exist in other contexts as well, why would it not be
applicable as well?

Regarding the argument that "filtering" is somehow different, isn't
pagination or archival just filtering of a different type, i.e. by
sequential order and/or by time rather than by other attributes of the feed
content?

I've not yet seen a strong argument for why making them different is
beneficial or helpful or why making them the same is harmful, but maybe I'm
just being missing something.

Finally, I want to be clear that in stating the our implementation, I wasn't
try to impose a particular generalized interpretation on feed id usage.   I
was just sharing experience and rationale as an implementor to inform the
discussion.    YMMV.

Cheers!

-- Kyle

> one present in the collection feed.

See above.  Stating that something doesn't have to be done a particular way
is not equivalent to saying it should not.

> only that, there cannot be correlation between the identifiers of

Again, I don't see this as an argument against having the same atom:id.  It
just informs that doing so isn't useful (but is not harmful) in that
particular context.

> different times from the same URL.

I think this particular aspect isn't open for debate, at least to me.  It
certainly seems significantly useful for the same feed retrieved
repetitively from the same url to have a constant atom:id.

---

From: Nikunj Mehta <[email-masked]>
Date: Tue, 12 Feb 2008 17:10:40 -0800

Kyle Marvin wrote:
> On Feb 11, 2008 8:32 PM, Nikunj Mehta <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> I can agree with the "cannot be any expectation" part of this, given 
> the general vagueness of specification around feed-level atom:id;  
> however, I'd observe that "not required to use the same atom:id"  due 
> to lack of clarity is distinctly different from "thus should not use 
> the same atom:id".
Postel's rule at work here. I am cautioning Atom users in general to not 
carry an expectation on the atom:id. Since it is not in the spec, it is 
gratuitous to use the same atom:id. I would do it too, but not sure that 
a total stranger would be able to use it meaningfully.
> I'm not necessarily following the logic.   See above statements.   A 
> use case for the benefits of sharing an atom:id (being able to tell 
> that all feed documents derive from the same source collection) has 
> been stated, and I suspect was the motivation for the sample usage in 
> RFC5005.    If this benefit is perceived to exist in other contexts as 
> well, why would it not be applicable as well?
I don't doubt the benefits. The question is - is there a way to create a 
standard that requires such sharing of atom:id across feed views? The 
converse is - if the sharing of atom:id cannot be standardized, then is 
there much benefit in reusing the atom:id?
> sequential order and/or by time rather than by other attributes of the 
> feed content?
No argument here - I say as much below
> beneficial or helpful or why making them the same is harmful, but 
> maybe I'm just being missing something.
>
> Finally, I want to be clear that in stating the our implementation, I 
> wasn't try to impose a particular generalized interpretation on feed 
> id usage.   I was just sharing experience and rationale as an 
> implementor to inform the discussion.    YMMV.
Its great the GData is benefiting from the specialized interpretation of 
the atom:id and I would like that to be the standard. Your experience is 
definitely beneficial to this discussion.
>     views
> See above.  Stating that something doesn't have to be done a 
> particular way is not equivalent to saying it should not.
>
>
> Again, I don't see this as an argument against having the same 
> atom:id.  It just informs that doing so isn't useful (but is not 
> harmful) in that particular context.
>
>
> I think this particular aspect isn't open for debate, at least to me.  
> It certainly seems significantly useful for the same feed retrieved 
>     that

-- 

Nikunj Mehta | XML Feeds Architect | +1.650.506.0679
Oracle Database Development
100 Oracle Parkway, Redwood Shores, CA 94065