Subject: Re: PaceRecommendIdScheme

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 03 Aug 2004 20:24:55 +0200

On Sat, 31 Jul 2004 23:41:14 +0200, Bjoern Hoehrmann <[email-masked]>  
wrote:

> If the element content identifies the feed it cannot change. Some entity
> might change the element content, but it would then be a different feed.
> While it might be undesirable to have different identifiers for feeds
> commonly perceived as equal, I don't think it is reasonable to make that
> a conformance criteria. It is not possible to write software that tests
> whether it changed with perfect reliability, for example.

Does this go for entries as well? If not, what differs entries from feeds  
in that respect?

> It is also not clear to me when two feeds are considered equivalent,
> which would be necessary to determine whether the id changed.

I'm not sure about that either. To be honest, I don't see a lot of reasons  
to have an identifier for atom:feed, unless it in some wierd way  
represents an atom:entry.

> If the author, title, tagline, and primary subject of the feed are
> changed, can it still be the same feed?

Not imho, no.

> I also see valid reasons to "change" the id, e.g. if the old id refers to
> a DNS name which is no longer controlled by the feed author.

This goes for entries as well. A common policy should be maintained for  
both, regardless of what that policy is.

> The same applies to uniqueness. While it might be undesirable if one
> identifier identifies different feeds, I do not think this requirement
> is reasonable. It would mean that I can  publish an Atom document with
> <id>tag:diveintomark.org,2001-07-29:/</id> it would render Mark's feed
> non-conforming. I do not think it should.

The non-conforming feed would of course be yours, but I get your point.  
This is not easy to test against either. The difference between entries  
and feeds here, is that while the sam entry is likely to show up in many  
different feeds, this doesn't apply to feeds.

> It would be better to include an informational note that publishers
> should take all reasonable steps to maintain the identifier.

Any idea how to note this?

> We can also specify that entry <id>s MUST be locally unique, and that
> intermediaries MUST NOT change <id>s, etc., but we should stick to
> things that are at least reliably human-testable.

Probably good enough, since I don't see a point in the atom:feed/atom:id  
anyway.

>> The URI scheme of atom:id MAY be a dereferencable URL scheme (like  
>> HTTP),
>> but MUST NOT  be expected to be one.
>
> I do not understand what beeing expected to be a dereferencable URL
> scheme means in this context.

Consumers shouldn't expect atom:id to be dereferencable, since not all  
URI's are. It's also imho not a good practice to have dereferencable ID's,  
since dereferencability often leads to mutable ID's, since objects on the  
web are moved all the time.

Producers should also not expect consumers to dereference their atom:id's,  
and thus isn't there much to gain from using HTTP URI's. Recommending  
another ID scheme also makes HTTP URI's less common, which hopefully will  
help generating more stable ID's in the future.

> Maybe you want to state that Atom software must not attempt to
> dereference the identifier?

I don't care if they attempt to do it, really. The point is that atom:id  
is just a URI, which may or may not be dereferencable.

> What is the use case for empty <id> elements?

Is «nothing» a valid URI? The text states that atom:id MUST be a URI.

> I think it is okay to prohibe relative references, but I think fragment
> identifiers should be allowed.

I can't see that the text prohibits people from using fragment  
identifiers. Should I write something explicit about that?

> I have no idea what the part about post-processing could mean,
> could you elaborate?

Having to resolve the base URI and with whatever method needed,  
concatenate this with the atom:id if it is relative, is (post) processing  
of the identifier. Or pre-processing. That depends on how you see it. The  
ID should at least not have to be fed through several layers of  
algorithmic mumbo jumbo to be fully qualified and ready to be compared  
with other ID's, however we express this.

> I don't think it is a good idea to duplicate all the content, it makes
> it rather difficult to learn how atom:id differs for feeds and entries.

Good point. I'll create a new «common construct» that explains about  
identifiers.

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 03 Aug 2004 23:25:30 +0200

* Asbjørn Ulsberg wrote:
>Does this go for entries as well?

Most of it, yes.

>Any idea how to note this?

Well, something like

  Sections preceded by "Note:" are informational...

  ...

  Note: Publishers should take all reasonable steps to maintain the
  identifier $rationale $best-practise-to-achieve-that ...

>web are moved all the time.

Well, yes, but what would it mean for software to expect something to
be dereferencable? They do if they attempt to dereference it or if it
provides means to the user to trigger such an attempt. If that is all
you mean, it would be better to state this more clearly.

>Is «nothing» a valid URI? The text states that atom:id MUST be a URI.

It actually states

  The content of this element, when present, MUST be a URI.

If the content is not present, the <id> element is empty. If that is not
allowed, then noting "when present" is pointless and misleading. And
yes, a string with a length of zero is a legal URI, but not a legal
absoluteURI.

>identifiers. Should I write something explicit about that?

There are many people confused by what the terms "URI", "URI Reference"
etc. mean, some people think "URI" may have a fragment identifier, some
disagree, some people think "URI" always starts with a scheme, some
think "URI" allows relative and absolute forms, etc., see 

  http://www.w3.org/mid/[email-masked]

for a related discussion. (Note that my text did not contain %f6,
W3C's broken mailing list archive software changed the text). As far
as I am concerned, "URI" can be both relative and absolute and the
only difference between "URI" and "URI Reference" is that the latter
allowes a fragment identifier. So your text prohibes fragment
identifiers.

>with other ID's, however we express this.

Since it must not relative, it seems to me that it would always be
"fully qualified", I certainly don't see which kind of processing
could make an identifier more "persistent" or "universally unique"
without changing the identifier. Could you give a counter example?
If not then it seems that the text about post-processing should be
removed.