Re: change proposal for issue-86, was: ISSUE-86 - atom-id-stability - Chairs Solicit Proposals

On Fri, 16 Apr 2010 10:28:00 -0700
"Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> It is easy to imagine further tools coming to depend on such an id
> being dereferenceable, and not reacting appropriately when paired
> with a tool that cannot produce dereferenceable URLs for such
> articles.  This will cause interop problems. 

This case is already covered by RFC4287:

| Though the IRI might use a dereferencable scheme, Atom
| Processors MUST NOT assume it can be dereferenced.

Any tool that uses the output of the HTML5 to Atom conversion algorithm
is by definition an Atom processor, so bound by RFC4287. I don't see
why HTML5 needs to place any additional restrictions on the
dereferencability of atom:id elements.

> I believe that there currently is no such appropriate algorithm for
> defining such a dereferenceable URL, and so it is best to simply say
> that the URL must be undereferenceable.

Assuming that the HTML5 to Atom conversion tool is running as a web
service, it's actually pretty simple to generate a dereferencable URL.

Assuming that http://example.com/input-document is the input
document, and the conversion tool is running at
http://atom.example.net, then:

1. atom.example.net generates a unique undereferencable identifier -
perhaps a hash of some kind - for each entry. Say one of those is
"ABC123ABC123".

2. It stores the following tuple in a database running on the
atom.example.net server:

  ("ABC123ABC123", "http://example.com/input-document")

3. It uses the following URL as an atom:id when outputting the Atom
document:

  <http://atom.example.net/entry-id/ABC123ABC123>

4. http://atom.example.net/entry-id is a script that takes an
identifier, looks it up in the database, and performs a 303 redirect to
the destination address.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Friday, 16 April 2010 18:09:46 UTC