Subject: Re: URI equivalence (was Re: PaceFeedEquivalence)

From: Graham Parks <[email-masked]>
Date: Tue, 03 Aug 2004 01:43:42 +0100

On 2 Aug 2004, at 8:43 am, Sam Ruby wrote:

> My preference is that if we are going to allow multiple comparison algorithms, I want rules in place
> to ensure that all such comparisons get the same result.

Why don't we do just that?

i) It is an error to provide ids that are meant to be the same that fail simple string comparison.
ii) It is an error to provide ids that are meant to be different but match after normalization.

I also don't ever see atom:id's being passed around by humans ever (what with not being dereferencable and all). 

Graham

---

From: Sam Ruby <[email-masked]>
Date: Mon, 02 Aug 2004 21:13:11 -0400

> ii) It is an error to provide ids that are meant to be different but match after normalization.

Who would one detect "meant to be different but match after normalization"?

Forgive me, but this sounds to me pretty much ? Removing paragraph about 
atom:id not working and trusting people to get it right ? [1]

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg08110.html

---

From: Graham Parks <[email-masked]>
Date: Tue, 03 Aug 2004 16:50:01 +0100

> Who would one detect "meant to be different but match after normalization"?

From a validator point of view, if a feed contains two different entries with ids like "http://www.example.com/" and "http://www.example.com:80/", you can say to some software these are duplicate ids. Basically, publishers need to make sure every id is different enough from the last if they intend them to be different. But if they intend them to be the same, they still need to be character for character the same. That way all comparison methods work.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Tue, 03 Aug 2004 12:51:48 -0400

Graham Parks wrote:

>> From a validator point of view, if a feed contains two different
>> entries with ids like "http://www.example.com/" and
>> "http://www.example.com:80/", you can say to some software these
>> are duplicate ids. Basically, publishers need to make sure every id
>> is different enough from the last if they intend them to be
>> different. But if they intend them to be the same, they still need
>> to be character for character the same. That way all comparison
>> methods work.

Pubsub plans to republish items from other sources.  They intend to be 
the same.  How does the feedvalidator verify this?

We are getting into areas of opinion.  Areas where reasonable people can 
reasonably disagree.  Certainly the feedvalidator can't verify intent - 
or even if pubsub considered the original ids at all or simply elected 
to regenerate identifiers anew.

Given that spiders are prone to aggresively normalize, and that the 
results of spidering is likely to be republished, I would like to do one 
of two things:

1) Either nail down precisely the comparison method so that 
implementations that do otherwise are clearly wrong.

2) Nail down the canonicalization rules so that implementation methods 
that vary within those bounds - and only within those bounds - will 
interoperate.

Spending a few minutes with .Net's Sytem.URI class, and in particular 
it's constructor, .ToString() and .Equals() methods, indicate to me that 
even non-spiders will tend to normalize; so the second approach seems 
the most prudent.

Console.WriteLine(new Uri("HTTP://EXAMPLE.COM:80").ToString());

   => http://example.com/

Console.WriteLine(new Uri("HTTP://EXAMPLE.COM/%7ESmith").ToString());

   => http://example.com/~Smith

- Sam Ruby

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 04 Aug 2004 03:43:11 +0200

>even non-spiders will tend to normalize; so the second approach seems 

It seems quite odd to use an URI processor to process the content of
atom:id elements unless you want to normalize the URI or process it in
other ways (i.e., read meaning into something that is defined to have
no meaning). Why would you do it?