RE: The <id> element

sandro@roke.hawke.org wrote:

> [ Hmm.  I've been meaning to pay attention to Atom for a
> while, but I haven't found the time.  Now I'm jumping in
> on a mailing list I'm not on, because I was CC'd.  Let's
> see how far in I sink. ]

You're welcome to sink in how deep you want. The list is open
for everyone.

> I think what you're calling the "id" is supposed to be the
> (globally unique) name for some abstract entity being talking
> about -- a news item, a journal entry, an article

Yes.

> and what you're calling "link" is a (globally unique) name for
> a networked source of information about that thing.

The thing about <link> is that it most likely won't be globally
unique over time. But other than that, I agree.

> The announcement itself, meanwhile, should have its own URI.

Yes, most definately.

> It is a conceptual entity on its own.  It was written by a
> particular person, intended for release at a particular time,
> etc.

Yup. It should be represented in it's own form, e.g. atom:entry.

> All the mirrors and different pages presenting this announcement
> can be tied together using this one URI.  If some of them go away,
> you can search for others; they may not present exactly the same
> information, but they are talking about the same thing.

Exactly.

> I wish w3.org did this right, so I could show you the URI for the
> announcement itself, but it doesn't.

That's a shame.

> The home page RSS feed claims the URI for the annoucement itself is
> "http://www.w3.org/News/2003#item164".  That's the same name as that
> first anchor, so we have some ambiguous naming going on here.  Bad
> URI design.

True. Each article (or item, entry or whatever) doesn't necessarily
need to be obtainable in HTML, but it should be in some format. Atom
might be that format (or at least; I want it to be).

> Of course this is much much clearer with tag: URIs.

Yes, a great point for going with tag: URI ID's.

> If we used a tag to name the announcement itself, I'm pretty sure
> we'd never have confused it with one of the several web page
> presenting the announcement.  So I see the appeal of tags.

Great.

> But we're still better off using an http: URI to name the
> announcement itself.

Are we? What happens if the site moves (not very likely in W3C's
case, but nevertheless)?

> It should just be a URI which does NOT name an anchor or a
> web page.  It should either be a fragment URI for an RDF/XML page
> (they don't have anchors) or it should be served with an HTTP
> redirect (preferably "303 See Other") to the appropriate
> information source.

But the ID shouldn't only mean something to the originating site.
It should mean something to everyone, and it should be just as
unique and obtainable for everyone, without having to talk too
much with the source server.

> By being an http: URI, it can still be used by itself, and we
> don't *need* to carry a "link" around.

When it comes to globally uniqueness, I think we do.

> I said something this a bit differently on the ESW Wiki, near
> http://esw.w3.org/topic/DualUseUri .  Feel free to chip in
> there if you'd rather discuss this wiki-style.

I'd actually rather discuss this mailing list-style, but I might
as well discuss it on the Wiki if you prefer it. I'll have a look
at the Wiki, at least.

> (or maybe I should watch the Atom wiki.  Hrm.)

I think you should, regardless of this discussion. :)

> id   = "http://example.com/item/2423423"
> link = "http://example.com/briefly?2423423"
> link = "http://example.com/discuss?2423423"
> link = "http://mirror.example.net/briefly?2423423"
> 
> where id redirects to the first link.

I don't think this works very well for the mirror.example.com
case.

> If you lose example.com, and the newcomer lets your stuff rot,
> then folks will still be able to use the last link.  If the
> newcomer is evil and misuses your old stuff, people will be
> able to see a conflict between the links, and can potentially
> figure out what happened.

They can «potentially figure out what happened», yes. I don't
think that's good enough. I don't think they should need to
figure this out, especially not this way. They should get a
notice, but it shouldn't come implicitly through the change
of namespace in the ID's or something similar.

A move should be explicitly told about, but an entry should
be obtainable at the new place without changing it's ID.
After all, the entry is the same.

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

Received on Monday, 27 October 2003 13:02:45 UTC