RE: The <id> element

[Asbjørn Ulsberg <asbjorn.ulsberg@xxxxxx>]

Sean B. Palmer wrote:

> It's stalled due to IESG homework, and won't be picked up
> until a) sandro or TimK have the time and motivation to pick
> it up again

Do you think this is going to happen anytime soon?

> b) sandro or TimK find someone who has the time and motivation
> to pick it up again.

Doesn't the members of this list have (time and) motivation to
pick it up? I could of course do it, but I don't feel I have
the technical (nor administrative) expertice needed. If someone
could collaborate with me, I would be happy to try to finish
the specification.

> HTTP URIs probably make for good enough IDs.

The problem with URIs are that they too often get confused with
URLs, which is a problem with both namespace-URIs and could be
with <atom:id>. When people see a URL (or a URI that looks like
a URL), they have an undescribable urge to plunge it into a
browser.

I understand this urge very well, and I even have it myself.
Therefore I feel that any URI that looks like a URL in Atom
also should _be_ a URL. And if <id> is a URL, we don't need
<link>. Also, a URL may and will change over time, but <id>
needs to be constant, or permanent if you will.

So, I think <id> should _not_ be something that looks like
a URL, and that is why I like the 'tag' URI scheme. It
obfuscates the URI so it doesn't look «browser friendly»,
and therefore the «plunge urge» deminishes.

I think it's better to have a hashed string as an <id>,
than a plain wannabe-URL URI. That is, if we don't decide that
<id> should be in the 'tag' URI scheme.

-- 
Asbjørn Ulsberg           -=|=-          X-No-Archive: No
"He's a loathsome offensive brute, yet I can't look away"