On 31 Jan 2005, at 05:22, Tim Bray wrote:
On Jan 30, 2005, at 7:10 PM, Paul Hoffman wrote:
The content of an Identity construct SHOULD NOT be dereferenced, even when it comes from a
normally dereferencable scheme. There is no requirement for the content to represent a URI
where a version of the feed or entry may be found.
I'm +1 on this,
-1. And I *will* lie down in the road.
For "ongoing", I plan to use the same http: URIs for both the <atom:id> and <link rel="alternate">; I will manage (and have managed) my URI space so that they will meet the requirements of permanence, uniqueness, and so on. In this case the <atom:id> URI will absolutely be dereferenced, but only in its <link> role. The language above could be read as discouraging what I'm planning to do, and what I'm planning to do is perfectly good practice. Anyhow, per both IETF RFCs and the W3C web-architecture spec, no harm can be done merely by trying a GET on any URI, so saying SHOULD NOT is just bogus.
I was thinking of doing something similar with BlogEd. An entry id would point to the
directory containing each version of an Entry. The link would probably point to the exact
Entry version described by the atom xml entry in which it appears. By dereferencing the id
link one could with correct access permissions, see all the versions of an entry. Though
the usual behavior would be to default to the last one.
Perhaps a directory tree like this
2005/01/31/entry1/ <---- the id of all the entries below
2005/01/31/entry1/version1/ <---- the url of the link to the first version
2005/01/31/entry1/version1/entry.xml <---- my first published entry in atom xml
2005/01/31/entry1/version1/entry.html <---- first published entry as html
2005/01/31/entry1/version2/ <---- the url of the link to the second version
2005/01/31/entry1/version2/entry.xml <---- my first published entry in atom xml
2005/01/31/entry1/version2/entry.html <---- first published entry as html
so when, with a browser, you request http://.../2005/01/31/entry1/ you would always get the
latest version of the Entry in the format of the mime type requested.
And when you request http://.../2005/01/31/entry1/version1/ you get the first version
of your entry in the format of the mime type requested.
So my belief is also that if people really don't want id dereferenced they should
use a scheme specifically for that purpose. Those who do that may well have much
longer lived web sites, and their blogs may be more flexible in that they can be moved
from one server to the next -- but they may also be a lot more difficult to find.
One way to get people to have their cake and eat it too, may be to allow multiple id tags.
Since an id is an inverse functional relationship between an Entry a Resource this should
not cause any trouble. In any case there will never be any way you can limit the number of
names a thing has.
Henry Story
