Subject: On the assertion that it is unreasonable to require URI format for atom:id since some GUIDs are not URI's...

From: "Bob Wyman" <[email-masked]>
Date: Fri, 3 Sep 2004 14:53:34 -0400

It has been asserted on a number of occasions that it is unreasonable to
require atom:id to be a URI since:
	1. A number of applications generate useful ids in non-URI form.
	2. A number of types of GUID satisfy atom's "uniqueness"
requirements without having the form of a URI.
	While the statements above are certainly true, they don't lead to
the conclusion that atom:ids should not be required to be URIs.

	I can see no reason why it is unreasonable to require that any
non-URI ids be converted to URI form prior to being used as atom:ids. This
can, for instance, be simply accomplished appending the non-URI id to a
prefix in such a way that a URI-form atom:id results. For instance:
	Given the non-URI id "F1FABE79-25FC-46de-8C5A-2C6DB9D64333", one can
easily append something like http://example.com?guid=" to it to construct
the URI:
	http://Example.com?guid=F1FABE79-25FC-46de-8C5A-2C6DB9D64333
	Any requirement that the producing application might have to
retrieve the original non-URI id can be easily addressed by simply chopping
the prefix off the string.
	For those who object to constructing "fake" URL's, as in the example
above, they could use the tag: URI scheme (Yes, I know it isn't registered
yet!) to construct ids like the following:

	tag:example.com,20040903:F1FABE79-25FC-46de-8C5A-2C6DB9D64333

	As before, it is trivial to remove the prefix in order to get at the
original non-URI identifier.
	Some will say that it is an onerous requirement that they waste
bytes by appending the prefixes in the manner suggested above. However, I
would argue that consistency in the form of atom:ids is valuable enough and
provides enough interop enhancement so that this expense is reasonably
demanded.

		bob wyman

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2004 21:09:43 +0200

Bob Wyman wrote:

> ...

+1

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 3 Sep 2004 13:34:51 -0700

At 2:53 PM -0400 9/3/04, Bob Wyman wrote:
>non-URI ids be converted to URI form prior to being used as atom:ids.

+1. And this is coming from the few people who supported 
IDs-should-just-be-strings. It's really trivial to do the conversion 
to URIs, as has been shown many times on the list.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 04 Sep 2004 17:45:59 +0200

> non-URI ids be converted to URI form prior to being used as atom:ids.

It somewhat breaks the former ID, but since Atom specifies Atom, that  
doesn't really matter. As long as the ID in Atom is always the same, it  
doesn't matter very much what it is in CDF or RSS. Or does it?

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

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 4 Sep 2004 11:57:08 -0400

>> I can see no reason why it is unreasonable to require that any
non-URI 
>> ids be converted to URI form prior to being used as atom:ids.
> It somewhat breaks the former ID,
	Please help me understand... I can not see any reason why
converting a non-URI to a URI by appending some something to it would
"break" an ID. Perhaps I am not understanding what you mean by "break."
	My assumption is that an ID is either opaque, in which case it
shouldn't matter what prefix it is given, or, that if the ID has some
structure that is know to some processors, it should be easy for those
processors to remove whatever prefix, etc. was used to convert the ID to
a URI. Is this not the case?
	If your concern is an ability to treat ids as opaque strings and
yet be able to compare them with ids or guids found in CDF or RSS feeds,
then I would suggest that this sort of cross-format comparison should be
considered out-of-scope for Atom. Requirements for cross-format
compatibility would, in general, make it impossible to specify anything
in Atom that hadn't been specified before. This would not be reasonable.
	Have I missed something?

		bob wyman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 04 Sep 2004 18:15:55 +0200

On Sat, 4 Sep 2004 11:57:08 -0400, Bob Wyman <[email-masked]> wrote:

> Please help me understand... I can not see any reason why converting
> a non-URI to a URI by appending some something to it would "break"
> an ID.

If you consume RSS feeds and Atom feeds, how will you know that Company  
Abc's <guid  
isPermaLink="false">F1FABE79-25FC-46de-8C5A-2C6DB9D64333</guid> and  
<atom:id>http://abc.example.com/F1FABE79-25FC-46de-8C5A-2C6DB9D64333</atom:id>  
are the same ID's?

> If your concern is an ability to treat ids as opaque strings and yet be
> able to compare them with ids or guids found in CDF or RSS feeds,
> considered out-of-scope for Atom.

That's perfectly okay. But it should probably be given a bit thought and  
maybe even some language in the spec?

> Requirements for cross-format compatibility would, in general, make it
> impossible to specify anything in Atom that hadn't been specified before.

That's the exact problem we have with alternate links. And not to mention  
dates. If this wasn't an issue, we would probably have most of the Dublin  
Core dates in the specification a long time ago.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Sep 2004 18:28:59 +0200

> <atom:id>http://abc.example.com/F1FABE79-25FC-46de-8C5A-2C6DB9D64333</atom:id>  

The spec could define a normative standard mapping.

Julian

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 04 Sep 2004 18:41:28 +0200

On Sat, 04 Sep 2004 18:28:59 +0200, Julian Reschke <[email-masked]>  
wrote:

>> If you consume RSS feeds and Atom feeds, how will you know that  
>> Company  Abc's <guid isPermaLink="false">F1FABE79-25FC-46de-8C5A-
>> 2C6DB9D64333</guid> and <atom:id>http://abc.example.com/F1FABE79-
>> 25FC-46de-8C5A-2C6DB9D64333</atom:id> are the same ID's?
>

So we should define a standard URI prefix mechanism, and if that prefix is  
present, consumers MAY assume that the ID is a fragment of the full  
identifier, or should they compare the ID's with functions like  
'EndsWith()' and the likes?

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 4 Sep 2004 12:53:06 -0400

Julian Reschke wrote:
>> Company Abc's <guid  isPermaLink="false">F1FABE79-25FC-46de-
>> 8C5A-2C6DB9D64333</guid> and  <atom:idhttp://abc.example.com
>> /F1FABE79-25FC-46de-8C5A-2C6DB9D64333</atom:id> are the same ID's?

	This normative mapping could be easily accomplished using tag:
URIs. The atom specification could say that non-uri's should be prefaced
with:

	tag:atom.ietf.org,2004:noturi:

	Then, the RSS guid that Asbjørn uses in his example should be
re-written as follows:

tag:atom.ietf.org,2004:noturi:F1FABE79-25FC-46de-8C5A-2C6DB9D64333

	As such, it would be a URI, if it was globally unique in the
world of RSS, it would remain so in the world of Atom, and it is very
easy to extract the original RSS guid from the atom:id when doing
comparisions.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 10:28:35 -0700

> URIs. The atom specification could say that non-uri's should be 

At this moment, "tag:" is not a registered URI scheme.  Is anyone able 
to shed light on how the registration process is proceeding? -Tim

---

From: Sam Ruby <[email-masked]>
Date: Sat, 04 Sep 2004 14:35:11 -0400

> easy to extract the original RSS guid from the atom:id when doing

"globally unique in the world of RSS", eh?

Suggestion:
 
tag:blogs.law.harvard.edu/tech/rss,2002:F1FABE79-25FC-46de-8C5A-2C6DB9D64333

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Sun, 05 Sep 2004 07:59:24 +0900

At 18:28 04/09/04 +0200, Julian Reschke wrote:

>Asbj$B�S(Bn Ulsberg wrote:
>

No, this in to something the Atom spec should do.
URIs are designed so that new schemes can be defined,
that's how new classes of IDs get integrated into the Web.

If company ABC has their own very special abcguid thingy,
they should define how to map that into URIs, either
(and preferably) by using some subspace of some URI scheme
that they have control over, or by applying for a scheme.
That way, others (other specs,...) can use the same
URIs where appropriate.

Unless Atom defines a new access protocol (such as http or ftp,...)
or something similar, Atom should not be in the business of
defining URI syntax. HTML isn't, either, and that's a great
feature.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 05 Sep 2004 08:05:59 +0900

At 10:28 04/09/04 -0700, Tim Bray wrote:

>At this moment, "tag:" is not a registered URI scheme.  Is anyone able to 
>shed light on how the registration process is proceeding? -Tim

Tim Kindberg and I are working on resolving some I18N (IRI) related
issues. This shouldn't take too long anymore. There may be other
issues, but I don't know any.

Regards,    Martin.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 05 Sep 2004 09:45:49 +0200

> that's how new classes of IDs get integrated into the Web.

Not necessarily. Mapping to a set of URIs in an already existing scheme 
is absolutely acceptable.

> That way, others (other specs,...) can use the same

Right. However, if it's not a specific company but a related format 
(RSS) from which Atom wants to offer a smooth migration path, it makes 
sense to define that mapping within Atom (possibly in an appendix or a 
separate document discussing it's relationship to RSS).

> defining URI syntax. HTML isn't, either, and that's a great

I wasn't proposing to define any king of new syntax.

Julian

---

From: Danny Ayers <[email-masked]>
Date: Sun, 5 Sep 2004 13:18:11 +0200

> separate document discussing it's relationship to RSS).

I assume you are referring to RSS 2.0. I'm comfortable with this as
long as no ambiguity-introducing compromises are made within Atom.

Regarding RSS 1.0, mapping identifiers will be trivial as long as
http: URIs are allowed in Atom ids. The rss:item identifier, (in
@rdf:about) goes straight into atom:id.
Otherwise we may be looking at something pretty silly like prefixing
existing URIs with tag: to *reduce* their utility.

I would like to see the definition of the RSS 1.0 to Atom
mapping/migration presented as a part of a more complete description
of Atom described in RDF/OWL. A syntax-level mapping alone would
either leave the various existing extensions to RSS 1.0 high and dry,
or be complex but not complete. Note that some of these extensions are
used in virtually every feed: dc:creator, content:encoded etc.

I do think there should be a recommended description of Atom in
RDF/OWL alongside the other (informative) schemas, and would expect
migration docs to be solely informative, so none of this should delay
core activities.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Martin Duerst <[email-masked]>
Date: Mon, 06 Sep 2004 07:16:31 +0900

>Right. However, if it's not a specific company but a related format (RSS) 
>from which Atom wants to offer a smooth migration path, it makes sense to 
>define that mapping within Atom (possibly in an appendix or a separate 
>document discussing it's relationship to RSS).

Do you mean RSS 2.0, at
http://blogs.law.harvard.edu/tech/rss#ltguidgtSubelementOfLtitemgt ?

I see that defining a mapping from this to Atom ID (in an appendix or
a separate doc) is desirable. However, it will not be easy, in particular
in the case of isPermaLink="false". How are we going to distinguish
between:
- Real absolute uris
- Things that look like absolute uris, but do so just by chance
- Other stuff (may look like a relative uri)

Regards,    Martin.

---

From: Ian Davis <[email-masked]>
Date: Mon, 06 Sep 2004 11:17:40 +0100

> tag:blogs.law.harvard.edu/tech/rss,2002:F1FABE79-25FC-46de-8C5A-2C6DB9D64333 

Looking pretty similar to:

http://blogs.law.harvard.edu/tech/rss/2002#F1FABE79-25FC-46de-8C5A-2C6DB9D64333

I thought one of the reasons we were considering tag URIs in the first 
place was because people change paths and domains. If they can remember 
to preserve the atom:id when using tag URIs then why not http URIs?

It might be better to enable tag URIs with authority part that is more 
personal than domain/path, such as sha1 hash of email address:

tag:69e31bbcf58d432950127593e292a55975bc55fd,2004:myfirstpost

where

69e31bbcf58d432950127593e292a55975bc55fd

is the sha1 hash of

mailto:[email-masked]

FOAF uses sha1 hashes in just this way to associate email addresses with 
people. This would fit into the EBNF of the tag scheme rather nicely.

Ian

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 10:13:42 -0400

> to preserve the atom:id when using tag URIs then why not http URIs?

In 2002, the rss specification which defined the term "guid" existed at 
http://blogs.law.harvard.edu/tech/rss.  Even if the RSS specification 
were to move in 2006, that fact would no change.

> mailto:[email-masked]

Perhaps the TAG scheme should be extended to allow sha1 hashes of known 
quantities like email addresses in order to protect such things from 
harvesters.

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Mon, 06 Sep 2004 15:23:11 +0100

> were to move in 2006, that fact would no change.
Yes agreed. But my point is around the social aspects of ID maintenance. 
As Mark Pilgrim pointed out in his atom:id article, things that look 
like permalinks tend not to be when publishers switch publishing tools. 
Naive templates that use the currently configured domain name to 
generate an ID in the output rather than storing the full ID tend to be 
to blame here.

> quantities like email addresses in order to protect such things from 

Yes, this would be useful.

Ian

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 10:26:44 -0400

Ian Davis wrote:

>> In 2002, the rss specification which defined the term "guid" existed 
>> at http://blogs.law.harvard.edu/tech/rss.  Even if the RSS 
>> specification were to move in 2006, that fact would no change.
> 

In this specific case, this would not likely be a problem.  The scenario 
was: find a RSS 2.0 feed from a random source, with happened to have a 
guid (it's not required), which didn't happen to be a permalink (the 
default)... how does one consistently map that to a URI?

- Sam Ruby