Subject: PaceIdConstruct2 created

From: Graham <[email-masked]>
Date: Fri, 27 Aug 2004 12:07:20 -0700

(btw Can I use localhost or file: in my id?)

== Abstract ==

Replacement for PaceIdContruct based on 
[http://www.imc.org/atom-syntax/mail-archive/msg08572.html this 
message] from the mailing list.

== Status ==

Open

== Related paces ==

  * ["PaceIdContruct"]
  * ["PaceCanonicalIds"]
  * ["PaceComparingIds"]
  * ["PaceRecommendIdScheme"]

== Rationale ==

Replace clunky language in PaceIdConstruct

== Proposal ==

Replace section 4.2.6 and 5.5, append a section to "3. Common Atom 
Constructs", and modify section 5.12:

=== 3.5 Identification Constructs ===

Identification Constructs convey an identifier that is used to 
associate different instances of the same resource. Whenever a resource 
appears in an Atom Document, its identifier SHOULD be the same as any 
other times it has appeared in an Atom Document, and MUST NOT be the 
same as the identifier currently or formerly used for any other Atom 
resource.  Changes to the content or location of the resource MUST NOT 
change the identifier. All Atom Documents published by the same entity 
MUST use the same identifier for each respective resource they publish.

The content of an Identification Construct MUST be an absolute URI (see 
RFC 2396), which MAY come from any  scheme. When the URI  comes from a 
resolvable scheme, it MAY resolve to any resource, and MAY not resolve 
successfully. Implementations therefore MUST NOT assume there is any 
particular relationship between the resource the identifier belongs to 
and any resource it resolves to.

Two identifiers are considered to be the same when their content is 
composed of the same characters. Two identifiers whose that are 
composed of different characters but contain URIs that are themselves 
equivalent in a looser sense MUST NOT be considered the same. All 
comparisons MUST be case sensitive.

A system that accepts input in Atom format that it subsequently outputs 
in Atom format SHOULD pass through the values of all identifiers.

(append canonicalization and examples if you so wish)

=== 4.2.6  "atom:id" Element ===

"atom:id" is an Identification construct that identifies instances of 
the same feed. atom:head elements MUST contain an atom:id element, but 
MUST NOT contain more than one. Two feeds may be considered instances 
of one another when the atom:id element inside their respective 
atom:head elements contain the same identifier, but implementations 
MUST NOT assume they contain the same content.

=== 5.5  "atom:id" Element ===

"atom:id" is an Identification construct that identifies instances of 
the same entry. atom:entry elements MUST contain an atom:id element, 
but MUST NOT contain more than one. Two entries may be considered 
instances of one another when their atom:id elements contain same 
identifier, but implementations MUST NOT assume they contain the same 
content.

=== 5.12  "atom:origin" Element ===

The "atom:origin" element's content conveys the original source of the 
entry; e.g., the feed where the entry was first published.

If the source is an Atom Feed Document, then the content of atom:origin 
MUST be the identifier in that document's atom:head section.

(And if not?)

The content of this element MUST be a URI.  atom:entry elements MAY 
contain an atom:origin element, but MUST NOT contain more than one.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 27 Aug 2004 22:50:45 +0200

> (btw Can I use localhost or file: in my id?)

No to localhost, yes to file. Imho, that is.

> associate different instances of the same resource.

This sentence is a bit fuzzy. I understand what you mean (by reading on),  
but it isn't very clear.

> comparisons MUST be case sensitive.

This paragraph was very difficult to read. I'm not really sure how to  
implement what you write there.

> in Atom format SHOULD pass through the values of all identifiers.

«..that it subsequently..» should be «..which it subsequently..», no? And  
why only SHOULD and not MUST? Is it okay for synthetic feeds to create new  
ID's for Atom entries?

> the same feed.

Does it identify instances, really? Won't that give a new ID for each  
instance of the feed?

> atom:head elements MUST contain an atom:id element, but MUST NOT
> contain more than one. Two feeds may be considered instances

Also a bit fuzzy wording in this paragraph. I don't know how to improve it  
(yet), unfortunately.

> identifier, but implementations MUST NOT assume they contain the same

The same here as above.

> MUST be the identifier in that document's atom:head section.

«..then the content of atom:origin MUST be the Identification Construct of  
that feed» is clearer, imho.

> (And if not?)

What else than a feed may an Atom entry originate from?

> contain an atom:origin element, but MUST NOT contain more than one.

How many atom:origin elements may an entry contain? Zero? One? Infinate?

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Graham <[email-masked]>
Date: Fri, 27 Aug 2004 19:44:03 -0700

On 27 Aug 2004, at 1:50 pm, Asbjørn Ulsberg wrote:

> This sentence is a bit fuzzy. I understand what you mean (by reading 
> on), but it isn't very clear.

It's only meant to introduce the concept, nothing more.

> implement what you write there.

That middle sentence needs a bit of reconfiguration, I admit. But it's 
clear enough to me.

> «..that it subsequently..» should be «..which it subsequently..», no?

I never know the correct grammar there.

> And why only SHOULD and not MUST? Is it okay for synthetic feeds to 
> create new ID's for Atom entries?

MUST implies that software at the other end can rely on the same entry 
arriving from two different sources always having the same id, and I 
don't think it can. "system" describes much more than synthetic feeds - 
it could have been in RSS, HTML, PDF or dead-tree format while crossing 
the system. SHOULD is as strong as is viable.

> Does it identify instances, really? Won't that give a new ID for each 

I'll replace identfies with associates.

> «..then the content of atom:origin MUST be the Identification 
> Construct of that feed» is clearer, imho.

Yes, but we haven't defined such a thing.

> What else than a feed may an Atom entry originate from?

I lifted that section from Tim's version, though I added the question. 
I presume HTML or RSS, but it doesn't say what to put in atom:origin if 
so.

> How many atom:origin elements may an entry contain? Zero? One? 

Doesn't that specify exactly 0 or 1?

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 28 Aug 2004 00:46:10 -0400

> (btw Can I use localhost or file: in my id?)

Or private IP ranges (e.g. 192.168.1.1)...

Gah! I guess so. What happens when someone puts that stuff in <img> src? 
I really do need to try some webpages with my friendly neighborhood 
Tomcat Manager App's URIs in the src attribute.

> Identification Constructs convey an identifier that is used to associate 
> different instances of the same resource. Whenever a resource appears in 
> an Atom Document, its identifier SHOULD be the same as any other times 
> it has appeared in an Atom Document, and MUST NOT be the same as the 
> identifier currently or formerly used for any other Atom resource.  
> Changes to the content or location of the resource MUST NOT change the 
> identifier. 

You seem to be circling the definition of URIs and Resources. You've 
failed to get your intent across (IMHO), but I couldn't do better.

> All Atom Documents published by the same entity MUST use the 
> same identifier for each respective resource they publish.
> 
> RFC 2396), 

-1. URIs with fragments should be ok. Nitpick? Yes.

 > which MAY come from any  scheme.

This statement is redundant.

> When the URI  comes from a 

-1. If the scheme is resolvable, there sure is a relationship, even if 
it is "404 Not Found", for example. We don't get to define schemes.

> composed of the same characters. Two identifiers whose that are composed 
> of different characters but contain URIs that are themselves equivalent 
> in a looser sense MUST NOT be considered the same. All comparisons MUST 
> be case sensitive.
> 

Since the format spec defines Atom in terms of the XML Infoset, it would 
be best to to state that IDs are identical only when their Infoset props 
are identical (i.e. char-by-char).

> in Atom format SHOULD pass through the values of all identifiers.

The intent here is good, the wording is not. Once again, I don't have an 
improvement to suggest.

Since this Pace puts for essentially the same ideas that PaceIdConstruct 
does, I think mnot should take this Pace into account when drafting 02. 
Beyond that, I don't see that any action can be taken at this time.

Diffs against the next draft could be more obviously beneficial.

Robert Sayre

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 28 Aug 2004 10:37:08 +0200

* Graham wrote:
>resource.

I am opposed to such conformance requirements that require universal
knowledge to determine conformance or such that allow anyone to make
my future Atom content non-conforming.

>Changes to the content or location of the resource MUST NOT 

I can't make sense of the last sentence here, what does it mean?

>in Atom format SHOULD pass through the values of all identifiers.

Why is this a SHOULD? What are cases where it would be acceptable or
even desired to behave that way?

>identifier, but implementations MUST NOT assume they contain the same 

What does it mean for an implementation to assume that two entries
contain the same content? What does it mean not to do that? This clearly
lacks a processing model, my understanding is that much of the date and
id discussions are just about how implementations determine whether they
present an entry as one the user might wish to read. There is not much
point in discussing when two IDs are considered equivalent if that does
not yield in clear implications for Atom implementations.

Say there are two feed which are equivalent as defined by XML C14N
except that the IDs in the document use a different host name, are
implementations that treat the entries in the feeds as equivalent
non-conforming?

Say there are two feeds that are equivalent as above except that the IDs
in the document use different case for the scheme component of the ID,
are implementations that treat the entries in the feeds as equivalent
non-conforming?

Say there are two entries for which human testing determines them as
very different yet they have the same ID, are implementations that treat
the entries as very different as opposed to treating one entry as a
modified version of the other entry non-conforming?

If such implementations are non-conforming, how reasonable is it to
expect that implementations will actually conform to such requirements?

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 28 Aug 2004 10:40:25 +0200

>What else than a feed may an Atom entry originate from?

What may it not originate from?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 11:22:38 +0200

> What may it not originate from?

It needs to originate from something with an identifyer, or else  
atom:origin makes no sense.

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 14:55:31 -0400

> my future Atom content non-conforming.

Yeah. That probably needs to be captured in the spec. It's still an 
improvement on just saying "universally unique".

> I can't make sense of the last sentence here, what does it mean?

You MUST always use the same ids for your own entries. If you're 
republishing someone else's (say, a feed of search engine results), 
it's only SHOULD.

> even desired to behave that way?

If someone is subscribed to a blog feed and a feed of search engine 
results, and entries from that blog show up in the search results, its 
beneficial to give the aggregator a hint of which entries are the same.

> contain the same content? What does it mean not to do that?

Without that sentence, someone might assume that when they find an 
entry with the same identifier as one they have previously seen, they 
may assume the content is the same and has not changed at all.

> There is not much point in discussing when two IDs are considered 
> equivalent if that does

"Two entries may be considered instances of one another when their 
atom:id elements contain same
identifier, but implementations MUST NOT assume they contain the same 
content."

That's a pretty clear implication, isn't it? The implementation knows 
that two entries are versions of one another, but does not know they 
contain the same content. After that, it's up to the application to 
decide whether to only show the most recent, or show a list of all 
versions, or whatever it chooses.

> implementations that treat the entries in the feeds as equivalent

Same content, different ids? The answer is of course, yes, but I also 
think it's outside the scope of the spec, and certainly of the atom:id 
spec. Can someone with more spec writing experience than me needs to 
answer this?

> modified version of the other entry non-conforming?

I said they "may" be considered versions of one another, not must. I 
don't think there's any need to be more explicit than that.

Graham

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 14:56:13 -0400

On 27 Aug 2004, at 9:46 pm, Robert Sayre wrote:

>> associate different instances of the same resource. Whenever a 
>> resource appears in an Atom Document, its identifier SHOULD be the 
>> same as any other times it has appeared in an Atom Document, and MUST 
>> NOT be the same as the identifier currently or formerly used for any 
>> other Atom resource.  Changes to the content or location of the 
>> resource MUST NOT change the identifier.
>

Yes. The first para describes them only conceptually, with the URI 
stuff left until the second and third. Similarly "resource" is left 
open because it literally defines a range of resources. The problem is 
that entries and feeds and have not been defined yet, so the 
Identification Construct can't be tied to entries and feeds until their 
specs. This points to a larger problem with the structure of the whole 
spec, I think.

>> All Atom Documents published by the same entity MUST use the same 
>> identifier for each respective resource they publish.
>> The content of an Identification Construct MUST be an absolute URI 
>> (see RFC 2396),
>

OK. I'm not completely au fait with that aspect of URI terminology.

> This statement is redundant.

Probably.

>> When the URI  comes from a resolvable scheme, it MAY resolve to any 
>> resource, and MAY not resolve successfully. Implementations therefore 
>> MUST NOT assume there is any particular relationship between the 
>> resource the identifier belongs to and any resource it resolves to.
>

The intention here is to avoid implementations assuming HTTP ids are 
permalinks. I don't think I'm redefining schemes - sure, there's a 
relationship between the URI and the web page, but that does not imply 
a relationship between the Atom entry and the web page.

> Since the format spec defines Atom in terms of the XML Infoset, it 
> would be best to to state that IDs are identical only when their 
> Infoset props are identical (i.e. char-by-char).

Yeah.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 28 Aug 2004 22:32:03 +0200

> republishing someone else's (say, a feed of search engine results),

Why only SHOULD for republishing? Is it okay to change the title and  
content of the entry as well? If not, why can atom:id change, but nothing  
else?

> may assume the content is the same and has not changed at all.

Well, that may be the case too. It's up to other parts of the entry (e.g.  
a 'modified' date) to give notification about whether the entry has  
changed or not. I think atom:id should be silent about that issue.

> don't think there's any need to be more explicit than that.

But is it necessary to mention at all?

---

From: Graham Parks <[email-masked]>
Date: Sat, 28 Aug 2004 16:55:57 -0400

>content of the entry as well? If not, why can atom:id change, but nothing  

As I said in the previous reply to you, the system can be much, much more complicated than, say, a script than takes Atom in one end and outputs it on the other. I don't think it's reasonable to assume the id (which is Atom specific) will be preserved if the entry gets changed to other formats on its way through.

>changed or not. I think atom:id should be silent about that issue.

That's what the sentence is there for. I don't think its unreasonable for someone unfamiliar with Atom to think if they have two entries with the same id they only need to process one of them. Think of email, where messages are immutable once sent, adn therefore two emails with the same id can be assumed to be the same.

>But is it necessary to mention at all?

We need to say something about what two entries containing the same id means, don't we?

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 28 Aug 2004 17:19:36 -0400

Asbjørn Ulsberg wrote:
> Why only SHOULD for republishing?
	Because a republisher may not have confidence in the correctness
of the atom:id. The republisher would give the item a new atom:id in
order to prevent any damage that might cause from republishing something
that incorrectly duplicated an atom:id used elsewhere. The republisher
needs a means (other than simply deleting entries) in order to prevent
being a tool in someone's attempt to attack the network. Changing the
atom:id can be one tool which, in unusual situations, might make sense
to use.

> Is it okay to change the title and content of the entry as well?
> If not, why can atom:id change, but nothing else?
	Atom:id is "special" because it is part of the identity
mechanism for an entry and uniqueness constraints exist. Title and
content have no such uniqueness constraints.

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 00:42:46 +0200

On Sat, 28 Aug 2004 16:55:57 -0400, Graham Parks <[email-masked]> wrote:

> As I said in the previous reply to you, the system can be much, much  
> more complicated than, say, a script than takes Atom in one end and  
> outputs it on the other.

Uhm, okay.

> I don't think it's reasonable to assume the id (which is Atom specific)
> will be preserved if the entry gets changed to other formats on its way
> through.

As far as I can tell, Atom isn't specifying anything else than Atom. What  
you do with atom:id if you re-publish an Atom entry in e.g. PDF is  
something out of scope for this specification and WG, afaik.

>> Well, that may be the case too. It's up to other parts of the entry  
>> (e.g. a 'modified' date) to give notification about whether the entry
>> has changed or not. I think atom:id should be silent about that issue.
>
> That's what the sentence is there for.

I don't think it should be there.

> I don't think its unreasonable for someone unfamiliar with Atom to think
> if they have two entries with the same id they only need to process one
> of them.

If so, the sentence needs to be rewritten. As it reads now, this is very  
unclear.

> We need to say something about what two entries containing the same id  

Okay, perhaps we do, but I don't think the text in PaceIdConstruct2 makes  
this any clearer.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 29 Aug 2004 00:58:03 +0200

On Sat, 28 Aug 2004 17:19:36 -0400, Bob Wyman <[email-masked]> wrote:

> that incorrectly duplicated an atom:id used elsewhere.

If that is the case, why do we even _have_ id's? Drop them entirely.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 29 Aug 2004 01:00:34 +0200

On Sat, 28 Aug 2004 17:19:36 -0400, Bob Wyman <[email-masked]> wrote:

> of the atom:id.

If re-publishers are allowed to mutate atom:id, doesn't that reduce the  
value of the construct? I say that atom:id should be immutable for  
absolutely all publishers on the planet, no matter where the re-published  
content came from.

If a re-publisher don't «trust» (how do you define trust in this context?)  
the content (be it atom:id or whatever), it's better not to re-publish the  
entry than to mutate parts of it -- especially atom:id, since that should  
be immutable.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 28 Aug 2004 17:11:32 -0600

On Saturday, August 28, 2004, at 05:00  PM, Asbjørn Ulsberg wrote:
> If re-publishers are allowed to mutate atom:id, doesn't that reduce 
> the value of the construct? I say that atom:id should be immutable for 
> absolutely all publishers on the planet, no matter where the 
> re-published content came from.
>
> If a re-publisher don't «trust» (how do you define trust in this 
> context?) the content (be it atom:id or whatever), it's better not to 
> re-publish the entry than to mutate parts of it -- especially atom:id, 
> since that should be immutable.
>
Let's say I'm taking Atom entries and storing parts of each entry in a 
database, but I'm not storing IDs because I don't plan on re-publishing 
later.  But later, I decide to go ahead and republish.  Or someone else 
who has access to the database decides to publish and Atom feed based 
on it.  Or the data gets published as an RSS feed which is converted to 
a ... which is converted to a ... which is converted to an Atom feed.  
There are a million ways the original ID could get lost.  In that case, 
the re-publisher should generate a new ID, and use that ID consistently 
when re-publishing the data.

Re-publishers SHOULD keep the ID the same--we are encouraging them 
strongly to track the ID.  But it simply won't happen in all cases.