Subject: Relative URI references

From: David Powell <[email-masked]>
Date: Tue, 27 Jul 2004 00:59:00 +0100

I've got a couple of questions about relative URIs in Atom:

Atom defines all of it's URI-ish elements to contain URIs. If XML Base
processing is to be applied to these elements, then don't they need to
be defined as URI references, rather than URIs?

Also, what is supposed to happen if relative URI references are used
in places where xml:base isn't in scope?

If relative URIs outside of the scope of xml:base are present in PUT
and POST requests, what are they relative to? The PostURI?, the
FeedURI?, the EditURI?  Or are they not allowed?

-- 
Dave

---

From: Tim Bray <[email-masked]>
Date: Mon, 26 Jul 2004 20:40:41 -0700

> be defined as URI references, rather than URIs?

In 2396classic terms, you're absolutely right.  Have to check 2396bis.

> in places where xml:base isn't in scope?

2396 specifies a hierarchy of ways that you can go about establishing a 
base URI.  While it seems obvious that these apply to Atom, it would 
probably be beneficial to say so explicitly in the drafts.

> FeedURI?, the EditURI?  Or are they not allowed?

Urgh, good questions.  Did you just volunteer to suggest some draft 
language? -Tim

---

From: David Powell <[email-masked]>
Date: Tue, 27 Jul 2004 22:42:45 +0100

> In 2396classic terms, you're absolutely right.  Have to check 2396bis.

Seems to be the same. "URIs" are always absolute, Only
"URI References" can be relative. It doesn't make sense to resolve an
absolute URI relative to xml:base - it is already resolved, so if we
are allowing xml:base, then this implies that all of our URIs should
actually be "URI References"

I'll write a Pace to fix this wording.  I'll do this separately to the
second issue, because I think this one is pretty uncontroversial and
applies predominately to AtomFormat, whereas the second issue is
with AtomPub.

> Urgh, good questions.  Did you just volunteer to suggest some draft 

Ok, but first here are my current thoughts on this. I have have two
options that I think are usable. If nobody says that my preference is
unimplementable then I'll write it up as a Pace.

Background
----------

RFC2396bis section 5.1 [1] describes how to resolve a relative URI
reference.

Rule 5.1.1 describes the use of xml:base like techniques.  Ok - we are
doing that.

Rule 5.1.2 describes the situation for encapsulated content like MHTML
- not relevant for us.

Rule 5.1.3 describes resolving the reference relative to the retrieval
URI - this works for retrieval of Atom documents, but isn't relevant
to publishing using AtomPP.

Rule 5.1.4 allows us to define our own application specific rules.

So in our current spec, if content containing relative URIs is POSTed
to a PostURI or PUT to an EditURI, and no xml:base is in scope, then
how to resolve this URI reference is currently undefined.

Options
-------

Option 1: URIRefs are resolved relative to the EditURI for PUTs
          and relative to the PostURI for POSTs at the time of creation by the server

Option 2: URIRefs are resolved relative to the FeedURI for PUTs and POSTs at
          the time of creation by the server

Option 3: Unresolvable URIRefs are left as-is, and are resolved by the client:
            a) relative to the FeedURI and
            b) relative to the EditURI
          depending on how they are accessed.

Option 4: Unresolvable URIRefs are left as-is, and are resolved by the client
          relative to the FeedURI irrespective of whether the entry is
          accessed via the FeedURI or the EditURI

Option 5: Unresolvable URIRefs are not allowed in AtomPP

My thoughts on the Options
--------------------------

1) and 2) are not feasible because the server would have to know what
elements contain URIRefs, including extension elements that it doesn't
recognize.  This is not possible without requiring schemas, which I
don't think that we want to do.

3) imposes the constraint that the FeedURI and EditURI would need to
be siblings in a URI hierarchy else they would resolve to different
URIs in each case. I thought that we were clear that it is the content
providers responsibility to define all URIs.
I think it would be reasonable to want to host the FeedURI on a
different server, so this option seems too restrictive.

4) would basically be a 5.1.4 rule [2] that we define for AtomPP.

Drawbacks:
 
  i) It would allow people to create really bad atom:id's that mutate
when they are moved to a different server.

 ii) It requires publishing clients to know about where the feed will
 be served from if they want to use relative URIs.

5) If people want to use relative URIs, they need to supply an
explicit xml:base.

It would prevent unresolvable relative URIs from being published via
AtomPP, but they could still appear in AtomFormat if they got put
there by other means, in which case they would be resolved relative to
the FeedURI using the standard rules [1]. This provides a migration
path for RSS feeds, .

This makes atom:entries self contained entities which can be put into
databases and served up from different places without getting involved
in arcane URI resolution rules.

The vote
--------

Option 5 is my preferred choice, but Option 4 would probably work too.

If anybody can not live without doing funny stuff with relative URIs
from publishing clients then say something now, otherwise I'll propose
that we don't allow relative URIs in AtomPP unless they are in the
scope of an xml:base declaration.

[1] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#base-uri
[2] http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#base-default

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Tue, 27 Jul 2004 18:16:59 -0400

> different server, so this option seems too restrictive.

This is only a restriction if entries must be serialized identically when
they appear in feeds (the spec doesn't say anything about this). Servers are
free to mangle URIs as they please, no? The status quo doesn't prevent
clients from supplying an xml:base.

Robert Sayre

---

From: David Powell <[email-masked]>
Date: Tue, 27 Jul 2004 23:50:16 +0100

> they appear in feeds (the spec doesn't say anything about this).

> Servers are free to mangle URIs as they please, no?

I'm not sure what you mean.

To serialize the representation of EditURI and FeedURI differently
then the server would need to know which elements contain URIs so that
it can resolve/mangle them - but that isn't possible because the
document can contain extension elements that the server doesn't
understand - some of these might hold URIs.

> The status quo doesn't prevent clients from supplying an xml:base.

No I agree, but I was trying to define what happens if the clients
don't supply an xml:base.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Wed, 28 Jul 2004 09:42:53 -0400

David Powell wrote:

> Tuesday, July 27, 2004, 11:16:59 PM, Robert Sayre wrote:
> 

> understand - some of these might hold URIs.

The client could mark the extensions "mustUnderstand" (not in the spec, 
but planned), it could make the URIs absolute, or it could supply an 
xml:base. Or we could specify a common link construct.

Perhaps I misunderstood. Were you proposing rules for extension 
elements, or all of Atom?

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 07:38:51 -0700

> Option 5: Unresolvable URIRefs are not allowed in AtomPP

Based on the discussion from you and Rob, if we modify this by saying 
"xml:base is allowed anywhere in AtomPP, and relative URIs may not be 
used unless the base URI has been established using xml:base" then I 
think we have something that's easy to explain and easy to understand 
and easy to implement.  I think that trying to write a set of base-URI 
rules around this URI and that URI and the other URI is going to be 
complex and tricky and easy to get wrong.  -Tim

---

From: Mark Baker <[email-masked]>
Date: Wed, 28 Jul 2004 11:00:27 -0400

+1

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 10:21:38 -0500

Tim Bray <[email-masked]> writes:

> Based on the discussion from you and Rob, if we modify this by
> saying "xml:base is allowed anywhere in AtomPP, and relative URIs
> may not be used unless the base URI has been established using
> xml:base" then I think we have something that's easy to explain and
> easy to understand and easy to implement.  I think that trying to
> write a set of base-URI rules around this URI and that URI and the
> other URI is going to be complex and tricky and easy to get wrong.

Rob, Arve, and I had a rather long discussion in #atom about this
yesterday[1], and it's more complex than that.

  1) the editing client, today, has no a priori knowledge of what the
     ultimate xml:base of the server will be, therefore depending on
     the context of where an xml:base declaration occurrs, it is
     likely "wrong" and must be overridden by the publishing system.

     The questions are: which ones are wrong and who knows better?
     The processer emitting the xml:base or the processor tasked with
     knowing the xml:base of certain locations?

  2) if we determine that the interaction between editing client and
     publishing system is "exempt" from xml:base processing (ie. it's
     entirely up to the publishing system), then we need to specify
     that xml:base processing does not occur in that interaction.

  3) if we determine that the server should indicate its known
     xml:base locations for various resources (links, ids, and
     content), that'll need to go in introspection and may be messy.

  4) some xml:base'd resources at the time the editing client is
     previewing content will be local (not yet published) and some
     will be remote (already published).  It should be noted that the
     client needs to be aware of that, along with (2) or (3).

We also ventured into other interactions and touched on test cases for
a variety of situations.  It feels to me like we've only begun to
scratch the surface of the issues with xml:base processing outside of
a purely "output" resource from a singly-based, known, web served
document instance.

  -- Ken

[1] http://www.ilrt.bris.ac.uk/discovery/chatlogs/atom/2004-07-27.html#T22-01-22

---

From: Elias Torres <[email-masked]>
Date: Wed, 28 Jul 2004 11:26:51 -0400

I have a question since I'm not an expert in xml:base. Can xml:base be
an attribute of any element in an Atom document? Would it mean then
that everytime you have a URI you must check upwards for any existing
xml:base? If that's all it takes, it's not that bad, but maybe we need
to remind people about that. Maybe there's an XPath that does it in
one query?

Elias Torres

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 28 Jul 2004 12:00:35 -0400

On Wed, 28 Jul 2004 11:26:51 -0400, Elias Torres <[email-masked]> wrote:
> an attribute of any element in an Atom document?

Yes.  Section 2 of the latest draft:

"""Any element in an Atom Document MAY have an xml:base attribute.  XML
   Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
   relative URI reference present in an Atom document.  This includes
   such elements and attributes as specified by Atom itself, as well as
   those specified by extensions to Atom."""

> Would it mean then
> xml:base?

Yes.  As per the XML:Base specification [1], if no xml:base is
present, the parent element's xml:base attribute is in scope (and so
on all the way up the tree).  A child's xml:base attribute can be a
relative URI, in which case it is relative to its parent xml:base
(after that is resolved relative to *its* parent, and so on all the
way up the tree).

You also need to track the base URI of the Atom document itself, which
in turn means you need to track the request URI and the
Content-Location header [2] (if present).  As per RFC 2616, the
Content-Location header can itself be relative, in which case it is
relative to the request URI.

As you might expect, I have written a few test cases [3] and
documentation [4] for my own feed parser.  Feedback welcome.

[1] http://www.w3.org/TR/xmlbase/
[2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14
[3] http://feedparser.org/tests/wellformed/base/
[4] http://feedparser.org/docs/resolving-relative-links.html

> If that's all it takes, it's not that bad, but maybe we need

I sincerely doubt it (my parser is based on SAX and uses a stack to
track base URIs going in and out of scope), but I would be happy to be
proved wrong.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Wed, 28 Jul 2004 09:13:18 -0700

> a purely "output" resource from a singly-based, known, web served

Candidate text for inclusion in our drafts would be welcome -Tim

---

From: Mark Baker <[email-masked]>
Date: Wed, 28 Jul 2004 13:33:56 -0400

> yesterday[1], and it's more complex than that.

Ay carumba, indeed it is.  I'll have to give this more thought.

Mark.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 28 Jul 2004 22:21:22 +0200

> Candidate text for inclusion in our drafts would be welcome -Tim

Specification text for atom:id exists in PaceRecommendIdScheme[1]:

   "If atom:id is dereferencable, it MUST be an absolute URI and MUST
    NOT be relative."

Not sure if the wording is the best, so we might need to work on that, but  
it at least captures the essence: Relative URI's should be forbidden in  
atom:id.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceRecommendIdScheme>

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

---

From: Elias Torres <[email-masked]>
Date: Wed, 28 Jul 2004 16:39:54 -0400

I'd say that atom:id MUST be an absolute URI always, whether is
dereferencable or not.

Elias

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 28 Jul 2004 23:10:25 +0200

> I'd say that atom:id MUST be an absolute URI always, whether is

Sure. Spec text changed to:

   "atom:id MUST NOT under any circumstance be relative. It MUST
    always be a complete, opaque and absolute URI that doesn't
    require any post-processing to fulfil the above requirements
    for persistency and universally uniqueness."

---

From: James M Snell <[email-masked]>
Date: Wed, 28 Jul 2004 15:13:41 -0600

+1 to atom:id ALWAYS being an absolute URI

- James M Snell
  [email-masked]
  http://www.ibm.com
  (877) 511-5082 / Office
  930-1979 / Tie Line

Elias Torres <[email-masked]> 
Sent by: [email-masked]
07/28/2004 01:39 PM
Please respond to
elias

To
"Asbjørn Ulsberg" <[email-masked]>
cc
Tim Bray <[email-masked]>, Atom-Syntax <[email-masked]>
Subject
Re: Relative URI references

Elias

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 18:09:12 -0400

Asbjørn Ulsberg wrote:
> Not sure if the wording is the best, so we might need to work on that, 
> but  it at least captures the essence: Relative URI's should be 
> forbidden in  atom:id.

This seems rather extreme.  The original question was about xml:base. 
If this is the answer to xml:base, then this approach should be done 
throughout the spec.  If not, there should be some rationalle as to why 
ids are different.

- Sam Ruby

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jul 2004 00:48:15 +0200

>    for persistency and universally uniqueness."

1) Just point to the correct production in RFC2396 ot RFC2396bis,

2) what does it mean for a URI to be "opaque"?

Julian

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

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 01:29:30 +0200

On Wed, 28 Jul 2004 18:09:12 -0400, Sam Ruby <[email-masked]>  
wrote:

> This seems rather extreme.  The original question was about xml:base. If  
> this is the answer to xml:base, then this approach should be done  

ID's are different because they need to be opaque and MUST never change.  
URI's everywhere else in Atom haven't got those requirements and  
restrictions on them. They can change, be dereferenced and whatever by  
whoever, whenever. This doesn't apply for atom:id, though. The single most  
facets of an ID is that it is unique and immutable.

Immutability is extremely hard to maintain if the ID itself is dynamic.  
There is of course a limit in how dynamic it can be, but just moving an  
entry from a location to another within the same site, will make the ID  
change if the relative ID isn't resolved and made absolute. If the site  
moves to a different domain, the ID will also change unless it is resolved  
and made absolute.

I can't think of one single good reason to have relative URI's in atom:id.  
Having different processing on different URI's might be bad, but then we  
should either disallow all relative URI's in Atom, or explicitly say where  
they are and aren't allowed. Where I think relative URI's are most useful,  
is within <content>. Thus could 'xml:base' be allowed on the <content>  
element and also relative URI's inside <content> be perfectly valid, but  
verywhere else in Atom should URI's be absolute.

I don't really care what consequences it has for the rest of the URI's in  
Atom that atom:id MUST be absolute. If all other URI's must be absolute as  
well then; fine. It's still much more important to have immutable and  
unique ID's than it is to save a few bytes in the referenced URI's. Imho,  
at least.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 01:41:41 +0200

> 1) Just point to the correct production in RFC2396 ot RFC2396bis,

Where in the text would those references go, exactly?

> 2) what does it mean for a URI to be "opaque"?

«Opaque» is probably not the right word. What I mean is that the string[1]  
inside atom:id should be straight-forward to understand and do something  
useful with. To be able to use the string as an identifier, you should  
only have to extract it without any further processing. It's just a unique  
string.

At the second you begin to add a lot of processing and complex rules on  
what to do with atom:id if it's relative and so on, you will increase the  
possibility of having mutated, non-unique ID's significantly. If we agree  
that the main purpose of an ID is to identify the resource, and not «be»  
anything but a plain stupid string, we at least have a common ground we  
can move in the same direction from.

I hope that it's not more important for an ID to be an URI and thus allow  
for everything that is possible to do with every URI scheme in existance,  
than it is for an ID to be globally, and hopefully universally, unique and  
immutable.

____
[1] I refrain myself from using the term 'URI' since I believe URI's as  
ID's give us absolutely zip.

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 28 Jul 2004 19:48:07 -0400

> ID's are different because they need to be opaque and MUST never change.

This is true but has no apparent relation to whether the opaque,
unique, unchanging ID is expressed as a relative URI.

> whoever, whenever.

This is not true.  There is no requirement that any URI anywhere in
Atom be dereferenceable.  For example,
http://intertwingly.net/wiki/pie/PaceLinkParent contains an example of
undereferenceable URIs pointing to a parent entry.

> I can't think of one single good reason to have relative URI's in atom:id.

(paraphrasing Daniel Dennett) First it starts innocently with "I can
not conceive of X." But then the philosopher goes too far, sliding
into "No one can conceive of X." And then they go completely
overboard: "It is inconceiveable that X." I don"t have a quarrel with
the original premise, but I draw a different conclusion: "Try harder."

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 20:33:29 -0400

> I can't think of one single good reason to have relative URI's in 

If you look closely, you will see that I use relative URI's in my 
current Atom feed: http://www.intertwingly.net/blog/index.atom

I've also mentioned a reason why this might be a good idea here: 
http://www.intertwingly.net/blog/2004/03/30/Uniqueness

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 02:37:13 +0200

> unique, unchanging ID is expressed as a relative URI.

So, the fact that the ID needs to be resolved before it is complete and  
useful, isn't apparent?

> This is not true.

Well okay. Not always, at least.

> There is no requirement that any URI anywhere in Atom be dereferenceable.

No. My point was that xml:id has higher requirements than other URI's in  
Atom. Other URI's are not immutable, for example.

> not conceive of X." [...]

Instead of being philosophical: Do you have a compelling reason or use  
case for ever having a relative URI in atom:id?

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 08:24:27 +0200

> current Atom feed: http://www.intertwingly.net/blog/index.atom

And the good reason to do this, is? Whenever an entry in that feed gets  
syndicated, moved or whatever, it will need to be resolved and made  
absolute. Why move that responsibility up to users of your feed or cause  
potential problems for yourself in the future, when they can be fixed with  
absolute URI's now?

Also, if you asked a million Bob's, they would not tell you that the ID's  
in that feed were relative. They would tell you that the ID's were an  
integer. Moving the responsibility of preserving uniqueness to consumers  
is imho a bad idea.

> http://www.intertwingly.net/blog/2004/03/30/Uniqueness

Sorry, but I can't agree that this is a good idea. It might be if  
consumers find out somehow that «Hey, this possibly can't be unique!» and  
therefore concat the in-entry ID's with the domain they're fetched from,  
but if you place such a responsibility on consumers, what will happen when  
the feeds move? Will the producer suddenly change his mind and make the  
ID's absolute, to preserve them? If so, should the consumer pay attention  
to this, and stop concating the ID with the domain?

Allowing for relative URI's create a worms nest of problems we really  
can't have and don't need. I don't understand why that's a good idea.

---

From: "Andreas Sewe" <[email-masked]>
Date: Thu, 29 Jul 2004 08:39:35 +0200

> throughout the spec.  If not, there should be some rationalle as to why

Well, notably the XML Namespaces recommendation deprecates the use of relative
URI references, and I would argue that atom:id is a case comparable to xmlns,
given that both are to be considered opaque and not necessarily
dereferenceable.

Furthermore the XML Base recommendation [1] states:

> Namespaces in XML [XML Names] uses URI references, which as currently
> defined should not be resolved relative to the base URI defined by xml:base
> for the purposes of namespace identification. [...]

Since identification is exactly what atom:id is meant for, being not
dereferenceable, so I would say xml:base should not apply to atom:id. But then
again it would be even better when atom:id is limited to absolute URIs.

Regards,

Andreas Sewe

[1]: <http://www.w3.org/TR/xmlbase/>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 29 Jul 2004 09:30:07 +0200

Asbjørn Ulsberg wrote:

> 
> On Thu, 29 Jul 2004 00:48:15 +0200, Julian Reschke 
> <[email-masked]>  wrote:
> 

Such as...:

   "atom:id MUST be an absolute URI (see "absoluteURI", RFC2396, section
    3). ..."

> «Opaque» is probably not the right word. What I mean is that the 
> string[1]  inside atom:id should be straight-forward to understand and 
> do something  useful with. To be able to use the string as an 
> identifier, you should  only have to extract it without any further 
> processing. It's just a unique  string.

If this is for detection of duplicates, the only thing the spec should 
say is how two given identifiers are to be compared. There are several 
layers of URI equivalence, and we'll need a layer that's works well with 
arbitrary schemes -- maybe simple character-by-character conversion is 
just fine.

> what to do with atom:id if it's relative and so on, you will increase 
> the  possibility of having mutated, non-unique ID's significantly. If we 
> agree  that the main purpose of an ID is to identify the resource, and 
> not «be»  anything but a plain stupid string, we at least have a common 
> ground we  can move in the same direction from.

I absolutely agree that anything except an absoluteURI doesn't make 
sense here...

> I hope that it's not more important for an ID to be an URI and thus 
> allow  for everything that is possible to do with every URI scheme in 
> existance,  than it is for an ID to be globally, and hopefully 
> universally, unique and  immutable.

But for the ID to have all these attributes, it *needs* to be a URI (so 
some other syntactical construct we can all agree on), otherwise there's 
no way to avoid collsions).

Julian

---

From: Eric Scheid <[email-masked]>
Date: Thu, 29 Jul 2004 17:35:33 +1000

> current Atom feed: http://www.intertwingly.net/blog/index.atom

I note that there are neither xml:base nor a http-header Location: to
establish what the base URI is, and since that same resource can be fetched
from both these URLs...

    http://intertwingly.net/blog/index.atom
    http://www.intertwingly.net/blog/index.atom

that means the <id>s in your feed can be different.

Hmmm ... I can also access that resource by the following URL, and similar
variations:

        http://foo:[email-masked]/blog/index.atom

Your relative URI id's are thus broken, IMHO.

If you can get this wrong, what do you think Bob will likely do?

e.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 09:27:12 -0400

> that means the <id>s in your feed can be different.

Good point.  At a minimum, that is worthy of an informative note.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 10:14:25 -0400

Asbjørn Ulsberg wrote:
> consumers find out somehow that «Hey, this possibly can't be unique!» 
> and  therefore concat the in-entry ID's with the domain they're fetched 
> from,

This is *NOT* a matter of consumers finding out "somehow" that «Hey, 
this possibly can't be unique!».  Please read section 3.1 of RFC 2396:

    Relative URI references are distinguished from absolute URI in that
    they do not begin with a scheme name.  Instead, the scheme is
    inherited from the base URI

A proposal to disallow relative URIs everywhere would be logically 
self-consistent.  I would prefer we did not go that way, but I could 
understand that postion.

I can also see an argument as to why certain elements are intrinsicly 
different and therefore need to be handled differently from the rest 
being brought forth.

But to disallow relative URIs in one element because Asbjørn is unable 
to see a good reason for them, and is unable or unwilling to understand 
that relative URIs can be distinguised from absolute URIs with a simple 
test: "is there a scheme present?"... well, sorry, I don't find that 
sufficient reason.

In any case, a rationalle of "The Atom specification should recommend an 
URI scheme to use for atom:id." is insufficient.  PaceRecommendIdScheme 
needs to be updated.

- Sam Ruby

---

From: Toru Marumoto <[email-masked]>
Date: Fri, 30 Jul 2004 01:50:14 +0900

>current Atom feed: http://www.intertwingly.net/blog/index.atom

Oh, that's why I couldn't read your article with my Atom aggregator..;-)

I think there is a risk of using relatibve URI's *without providing
 a base url in the feed*.

what if you use some online aggregator services, such as Blogline.com?
what if you wanted to transform atom into html using XSLT [1] locally?
what if the feed was to be served via RSS/Atom search engines?

I tested on several aggregators, and sadly they failed to point to the 
right address.

[1]http://www.witha.jp/HepCat/files/default.xsl.txt

Toru Marumoto
     see you on the web!
________________________________

--------------------------------
__________________________________________________
GANBARE! NIPPON!
Yahoo! JAPAN JOC OFFICIAL INTERNET PORTAL SITE
http://mail.ganbare-nippon.yahoo.co.jp/

---

From: James Robertson <[email-masked]>
Date: Thu, 29 Jul 2004 12:52:34 -0400

Umm, what failed to point to the right address?  I just tested that feed in 
BottomFeeder, and I didn't see any obvious problems

>[1]http://www.witha.jp/HepCat/files/default.xsl.txt

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
[email-masked]

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 19:58:33 +0200

>     inherited from the base URI

Do we reference RFC 2396 and this particular paragraph, regarding  
resolution of atom:id, in the specification, so Bob will easilly find this  
out? No we don't. We probably should. I still don't think that's enough.

> self-consistent.  I would prefer we did not go that way, but I could  

I don't see why we need to forbid relative URI's for all Atom elements,  
but if consistency is that important, then okay.

> different and therefore need to be handled differently from the rest  

I'm not sure what the specific use case for xml:base and relative URI's  
is, but I think that it's more useful on <content> than any other element  
inside Atom. This would have to be confirmed with and by the tool vendors,  
though.

> test: "is there a scheme present?"... well, sorry, I don't find that  

Okay. Good point. What do you expect Bob to do, both as a consumer and  
producer, when the feed of the entry which has relative ID's in it, moves?

And would you place a high bet on that Bob is able to provide a correct  
Content-Location header or xml:base to even make the relative atom:id  
resolvable?

> URI scheme to use for atom:id." is insufficient.  PaceRecommendIdScheme  

I need a better rationale in the pace?

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 14:05:50 -0400

> but if consistency is that important, then okay.

[snip]

>> But to disallow relative URIs in one element because Asbjørn is 
>> unable  to see a good reason for them, and is unable or unwilling to 
>> understand  that relative URIs can be distinguised from absolute URIs 
>> with a simple  test: "is there a scheme present?"... well, sorry, I 
>> don't find that  sufficient reason.
> 

If Bob uses relative URIs and moves his feed, then he will need to 
update his relative URIs to match.  All such relative URIs, not just 
<atom:id>.  If you want to argue that relative URIs are mostly OK, but 
not for the id tag, you need to focus on arguments that support that 
point.  Good examples of such arguments can be found at:

http://www.imc.org/atom-syntax/mail-archive/msg08013.html

>> In any case, a rationalle of "The Atom specification should recommend 
>> an  URI scheme to use for atom:id." is insufficient.  
>> PaceRecommendIdScheme  needs to be updated.
> 

The current rationale supports the following statement, and not much else:

    The recommended URI scheme for atom:id is "NewsML ID"

- Sam Ruby

---

From: Toru Marumoto <[email-masked]>
Date: Fri, 30 Jul 2004 03:59:15 +0900

I've tested in the latest version of SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
Oh, and Bloglines too. 

Toru Marumoto
     see you on the web!

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 20:37:27 +0200

>    "atom:id MUST be an absolute URI (see "absoluteURI", RFC2396, section

Done.

> say is how two given identifiers are to be compared.

Okay. I know there exist some specification text on this over at W3C, I  
just don't know where.

> I absolutely agree that anything except an absoluteURI doesn't make  

Great.

> no way to avoid collsions).

That's probably true, yes.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 29 Jul 2004 20:41:48 +0200

On Thu, 29 Jul 2004 14:05:50 -0400, Sam Ruby <[email-masked]>  
wrote:

> update his relative URIs to match.

I'm not sure what you're thinking of here. Should he change the xml:base  
or Content-Location header to match the new location of the feed? If so,  
that will genereate new ID's for all entries in the feed.

> All such relative URIs, not just <atom:id>.  If you want to argue that
> relative URIs are mostly OK, but not for the id tag, you need to focus
> on arguments that support that point.

I'm trying. :-o

>     The recommended URI scheme for atom:id is "NewsML ID"

Okay, I'll try to elaborate a bit more on why it is needed.

---

From: James Robertson <[email-masked]>
Date: Thu, 29 Jul 2004 16:04:18 -0400

ok, but what's the problem?  I'm seeing content, and the links look ok....

At 02:59 PM 7/29/2004, you wrote:

>I've tested in the latest version of 
>SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)... and so on.
>Oh, and Bloglines too.
>

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 29 Jul 2004 16:47:18 -0400

My Universal Feed Parser [1] supports relative URIs correctly.  That
plus BottomFeeder gives us two independent implementations, which
counts as rough consensus and running code.  We have test cases [2] so
the non-compliant applications can catch up.

[1] http://feedparser.org/
[2] http://diveintomark.org/tests/client/base/

-Mark

-- 
Cheers,
-Mark

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 17:08:03 -0400

> ok, but what's the problem?  I'm seeing content, and the links look ok....

The links (note: I said links, not ids) don't look OK in bloglines:

http://www.bloglines.com/preview?siteid=123923

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 14:41:48 -0700 (PDT)

> Good point.  At a minimum, that is worthy of an

This seems like an excellent reason to ban relative
URIs in atom:id elements. Or are aggregator
implementers expected to do perform scheme specific
URI comparisons when checking to see if two entries
are identical? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 14:49:14 -0700 (PDT)

> I've tested in the latest version of
SharpReader,RSSBandit,Headline-Reader(ja),HepCat(ja)...
> and so on.

I didn't implement xml:base support in RSS Bandit
since it would have been a hassle and I couldn't find
anyone who was using it besides Sam's Atom feed which
isn't listed on his feeds page so I doubt anyone
actually is subscribed to it. 

Once Atom hits 1.0 and how xml:base is to be utilized
in the spec is clearly spelled out I'll add support
for it to RSS Bandit. 

=====

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 17:57:51 -0400

> URI comparisons when checking to see if two entries

I think that you are asking an orthogonal question.

It is the possibility of ids being in schemes like HTTP that would 
introduce the possibility of scheme specific URI comparisons, not the 
ability for URIs to be expressed as being relative to xml:base.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 15:02:53 -0700 (PDT)

> ability for URIs to be expressed as being relative

If the consensus is that HTTP URLs should be allowed
for IDs then relative URIs should be banned. If a
specific URI scheme is mandated then it should be one
that doesn't have a relative URI scheme. Either way
relative URIs for IDs are a bad idea. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 18:24:30 -0400

> relative URIs for IDs are a bad idea. 

 From RFC 2396, section 1.4, paragraph 2:

     This document defines a scheme-independent `relative' form of URI
     reference that can be used in conjunction with a `base' URI (of a
     hierarchical scheme) to produce another URI.

HTTP may make scheme specific URI comparisons harder, but it certainly 
does not make relative URI resolution any easier or harder.

- Sam Ruby

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 29 Jul 2004 23:24:52 +0100

Dare Obasanjo wrote:

> for IDs then relative URIs should be banned. 

+1. This is a no-brainer.

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 29 Jul 2004 23:34:08 +0100

> does not make relative URI resolution any easier or harder.

I don't see what benefit there is in introducing a processing model 
to determine what are essentially surrogate ids when the ids can 
simply be declared - it strikes me as error prone. Why enable this 
for Atom ids?

cheers
Bill

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 15:41:45 -0700 (PDT)

> does not make relative URI resolution any easier or

Why do you keep bringing up HTTP? The issue I have is
with relative URIs for IDs. I don't care if Atom
mandates HTTP, FTP or NNTP as the URI scheme for IDs
in this case, relative URIs should not be allowed in
any case. 

=====

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail

---

From: Julian Reschke <[email-masked]>
Date: Fri, 30 Jul 2004 00:39:04 +0200

> for IDs then relative URIs should be banned. If a

What would be a relative HTTP URL (example?). As far as I understand, a 
relatve URI 
(<http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.5>) never 
starts with a scheme name, thus it's scheme is determined by the base 
URI it's resolved with...

> relative URIs for IDs are a bad idea. 

+1.

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 19:40:35 -0400

> in this case, relative URIs should not be allowed in

*sigh*

Recap: The original reason you gave for not wanting relative URIs was 
because it implied scheme specific comparisons.  My reply was: no, it is 
not relative URIs that implies that, but HTTP.  Then you gave HTTP as a 
reason why relative relative URIs should be banned.  Again, I said no, 
the HTTP scheme has no problem with relative URIs.

I certainly get that that you don't want relative URIs in IDs.  I'm 
presume that you have a reason behind this desire.  But if so, the 
arguments you have put forward related to scheme specific comparisons 
and HTTP aren't it.

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 17:36:55 -0700 (PDT)

> the HTTP scheme has no problem with relative URIs.

This has nothing to do with HTTP. It has everything to
do with relative URIs. 

Here's a thought experiment

1.) I subscribe to a feed via
ftp://[email-masked]/mainfeed.xml and another
via ftp://ftp.example.com/categoryfeed.xml

2.) The set of entries in mainfeed.xml is a superset
of the set of entries in categoryfeed.xml 

3.) Each entry uses a relative URI as the atom:id. 

4.) How do I tell that the many entries in
categoryfeed.xml have the same ID as those in
mainfeed.xml without doing scheme specific comparisons
after resolving xml:base rules? 

BONUS QUESTION
5.) What does this have to do with HTTP? 

> arguments you have put forward related to scheme

Hopefully it is clearer to you now. 

=====

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 21:17:51 -0400

> 3.) Each entry uses a relative URI as the atom:id. 

Stop there.  If we don't to keep the URI comparison rules simple, it 
isn't possible to do that in a valid way.  One of those would need to be 
absolute.

> after resolving xml:base rules? 

If the URI comparison rules are simple, then one simply compares the 
URIs after resolving xml:base rules.

> 5.) What does this have to do with HTTP? 

Nothing.  I guess I jumped to the wrong conclusion when you posed the 
issue as having to do with scheme specific URI comparisons.

> Hopefully it is clearer to you now. 

Yes, thanks for clarifying.

What I see is an argument that since relative URIs can't be used in some 
circumstances, they should be disallowed in all circumstances. 
PaceAtomIDIsNewsML takes this argument one step further and disallows 
both http and ftp as valid URI schemes for ID values.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Thu, 29 Jul 2004 20:10:45 -0600

On Thursday, July 29, 2004, at 07:17  PM, Sam Ruby wrote:
> isn't possible to do that in a valid way.  One of those would need to 
> be absolute.

...unless at least one of them specified xml:base explicitly, for 
example, in the first:

<feed xmlns="..." xml:base="ftp://ftp.example.com/">
...
<entry id="relative/path/to/something">
...

Right?  Or they could both specify xml:base explicitly:

<feed xmlns="..." xml:base="http://www.example.com/myblog/">
...
<entry id="relative/path/to/something">
...

---

From: Sam Ruby <[email-masked]>
Date: Thu, 29 Jul 2004 22:34:55 -0400

+1

- Sam Ruby

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 20:11:02 -0700 (PDT)

--- Sam Ruby <[email-masked]> wrote:
> > <feed xmlns="..."
> xml:base="http://www.example.com/myblog/">
> > ...

I'm not sure what this +1 is supposed to indicate. The
entire xml:base support thing in Atom seems like a
misfeature. The primary reason for needing something
like xml:base in syndication formats is to know how to
resolve relative URIs in [X]HTML content. 
Everywhere else it appears is overkill and
unncecessary complexity. More importantly it doesn't
even seem that most recent draft satisfies the only
real use case for using xml:base in the Atom
syndication format. 

Exactly what is served by the fact that you can use
relative URIs in IDs besides causing potential
problems in for feed consumers? Who is crying out for
the functionality of using relative URIs as values for
 atom:id or atom:link? On the other hand, it is a
major problem in RSS and Atom feeds today to determine
authoritatively how to resolve relative links in
content yet no one seems interested in discussing that
or tackling it in the spec. 

=====

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 30 Jul 2004 00:03:48 -0400

On Thu, 29 Jul 2004 20:11:02 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:
> On the other hand, it is a

This is what I've implemented:

http://feedparser.org/docs/resolving-relative-links.html

Is this what you've implemented?  If not, what did you do differently?
 Maybe I'll update my code, and my documentation.  Then let's talk
about how to express it in the spec.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Thu, 29 Jul 2004 21:14:04 -0700

I mostly agree with Dare on this one.  Putting a relative URI inside 
<atom:id> feels like bad practice to me, because there might not be an 
xml:base, and thus when you move a feed, or get it from different DNS 
aliases, you'll change the effective atom:id; and the whole reason the 
atom:id exists is to mitigate the effect of such cases.

I'm fine with relative URI references everywhere else atom specifies a 
URI, in fact I suspect there are going to be many cases where they are 
actually best practices. -Tim

---

From: Graham <[email-masked]>
Date: Fri, 30 Jul 2004 00:16:20 -0400

Allowing relative URIs in atom:id and trusting people to get it right ≡ 
Removing paragraph about atom:id not working and trusting people to get 
it right

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 29 Jul 2004 22:13:53 -0700 (PDT)

> about how to express it in the spec.

Nope, I haven't implemented xml:base support yet. if I
do it'll probably look like that. Except I don't see
where in your documentation you describe the
precedence of html:BASE[0] in your equation. 

My big beef with xml:base in Atom is twofold 

1.) Besides content I don't see the reason for having
xml:base support for any other elements besides adding
complexity to Atom feed consumers [especially those
using streaming parsers like SAX-based ones] 

2.) There is no spec text that unambiguously lets me
know that if the content type is text/html I should
use the xml:base of the content construct as the base
URI for resolving relative links. 

[0] http://www.w3.org/TR/REC-html40/struct/links.html#h-12.4

=====

---

From: Tim Bray <[email-masked]>
Date: Thu, 29 Jul 2004 22:55:16 -0700

> URI for resolving relative links.

Well, this is one of my major beefs with RSS.  When I first published 
my RSS feed, I carefully used relative URIs for everything, which works 
really well since I have a complete copy of 'ongoing' on my laptop and 
all the pointers to "/ongoing/this/that/foo" work perfectly both at 
"www.tbray.org" and "localhost".  Of course, I got complaints from the 
feedvalidator, and NetNewsWire broke in several irritating ways since 
its opinion of the base URI to use in resolving these differed from 
what I thought the obvious right answer was.

So, on #1 I flatly disagree, and on #2, if that's true that's a bug in 
the spec. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 08:09:51 +0200

> ...unless at least one of them specified xml:base explicitly, for  

Why does xml:base help? Either xml:base or a Content-Location header would  
be needed to do relative resolution in any case. That does still not  
change the fact that whenever the feed or entries move, the URI base would  
change, thus creating new ID's. Allowing for relative URI's in atom:id  
basically allows for dynamic ID's, like those generated with now().  
Dynamic ID's is far beyond «a bad idea», imho.

---

From: Bill de hÓra <[email-masked]>
Date: Fri, 30 Jul 2004 13:15:43 +0100

Dare Obasanjo wrote:

> misfeature. 

+1. for ids. I can appreciate it may be useful for linking

cheers
Bill

---

From: Antone Roundy <[email-masked]>
Date: Fri, 30 Jul 2004 09:10:36 -0600

On Friday, July 30, 2004, at 12:09  AM, Asbjørn Ulsberg wrote:
> On Thu, 29 Jul 2004 20:10:45 -0600, Antone Roundy 
> <[email-masked]> wrote:
>>> isn't possible to do that in a valid way.  One of those would need 
>>> to be absolute.
>>
> Why does xml:base help? Either xml:base or a Content-Location header 
> would be needed to do relative resolution in any case. That does still 
> not change the fact that whenever the feed or entries move, the URI 
> base would change, thus creating new ID's. Allowing for relative URI's 
> in atom:id basically allows for dynamic ID's, like those generated 
> with now(). Dynamic ID's is far beyond «a bad idea», imho.
>
This has nothing to do with the entries moving.  As long as xml:base 
continues to point to the old base URI, the atom:id's won't be changed. 
  What you're talking about it the problem with atom:id being 
deferencable, not with using xml:base to avoid repeating the same base 
portion of the URI in each id (or whatever other reasons it might be 
used for).

For the record, I'm not arguing either way on whether relative URIs 
should be allowed in atom:id.  The question of how to do relative URIs 
for entries that appear in feeds in multiple locations came up, and I 
suggested a solution--no editorializing was intended.

---

From: Toru Marumoto <[email-masked]>
Date: Sat, 31 Jul 2004 02:26:53 +0900

>counts as rough consensus and running code.  

Actually, I just tested in BottomFeeder. I see it's having some problem handling relative
URIs. When I try to navigate to the original page, a dialog shows up; "No Link Provided".
I tested other atom feeds that uses abusolute URIs, and there was no problem.

I just don't see any benefits of using relative URIs in atom:link. IMHO, of cource.

Toru Marumoto
     see you on the web!

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 21:04:51 +0200

> continues to point to the old base URI, the atom:id's won't be changed.

So, what this basically means is that authors must put xml:base on the  
atom:id element:

   <atom:id xml:base="http://example.com/blog/">3287234</atom:id>

Because the base URI for the rest of the document could (or would, if it  
has moved) be 'http://example.com/blog/moved/here'. Now, what does anyone  
gain from this? The only «gain» I see, is problems. Problems with making  
it much more difficult to process the ID and preserving and retaining it  
immutable and unique.

> What you're talking about it the problem with atom:id being deferencable,
> not with using xml:base to avoid repeating the same base portion of the
> URI in each id (or whatever other reasons it might be used for).

No, I'm not talking about deferencability, although relative URI's in  
atom:id very often could be deferencable.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 30 Jul 2004 13:19:23 -0600

On Friday, July 30, 2004, at 01:04  PM, Asbjørn Ulsberg wrote:
> Because the base URI for the rest of the document could (or would, if 
> it has moved) be 'http://example.com/blog/moved/here'. Now, what does 
> anyone gain from this? The only «gain» I see, is problems. Problems 
> with making it much more difficult to process the ID and preserving 
> and retaining it immutable and unique.
>
If a feed is only using relative URIs for atom:id, and if they're going 
to continue using the same base for new entries after the move, they 
could conceivably still use the old xml:base.  That would be a bit odd 
though.

A more practical approach than specifying xml:base for every old entry 
would be to write out the entire ID explicitly for old entries:

<atom:id>http://example.com/blog/3287234</atom:id>

They'd have to have some way to determine which entries were old, and 
thus had the old base URI (unless they'd always been storing the whole 
thing locally but shortening it when publishing the feed).

But once again, I'm not necessarily advocating relative URIs for 
atom:id.  The arguments against seem stronger than the arguments for, 
but perhaps not strong enough to forbid it.  It may be that clearly 
pointing out the risks of doing so, and what one might have to do if 
their base URI changes would be enough.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 30 Jul 2004 22:22:04 +0200

> could conceivably still use the old xml:base.  That would be a bit odd  

Yes, it's odd. Everything regarding relative URI's in atom:id is imho odd.

> <atom:id>http://example.com/blog/3287234</atom:id>

Of course. But then what's the point in not doing that in the first place?  
E.g., what is gained by not providing an absolute URI to begin with? I  
know what's «lost»:

   1. All consumers need to process the ID to make it absolute.

   2. All consumers need to know that any URI in atom:id that isnt't
      prefixed with a scheme, is relative.

   3. The publisher needs to provide either Content-Location or xml:base
      to make it possible for the consumer to process atom:id.

   4. When the author moves a feed or entry, she will have to either
      resolve all relative ID's and make them absolute, or apply the
      correct xml:base on all atom:id's that are affected by the
      relocation.

   5. The author needs to find out which ID's are affected by the
      relocation.

There are so many things that can go wrong in the above 5 points that I  
don't even know where to start. So, I'll start from top:

   1. Not all consumers know that this is needed. It's not stated
      anywhere that it is, and even if it was, you have no guarantee
      that they will read it. If they needn't process the ID, no
      such statement would be necessary.

   2. Few consumers know this. It's a simple rule, but it's not
      stated anywhere in the Atom specification, and even if it was,
      you have no guarantee that they will read it. If they needn't
      process the ID, no such statement would be necessary.

   3. Many authors just can't provide Content-Location, since
      the feeds are served statically. Having to provide xml:base
      also isn't stated explicitly anywhere, and even if it was,
      you have no guarantee that they will read it. If they needn't
      apply an URI base to the ID, no such statement would be
      necesarry.

   4. Authors will get this wrong or forget it. Either way, it needs
      to be explicitly stated in the specification. Even if it was,
      you have no guarantee that they will read it. If they just
      used an absolute URI to begin with, this wouldn't be an issue.

   5. This can be quite a hassle, and if entries are forgotten,
      they will have mutated ID's.

None of the above points would be an issue if the ID was absolute to begin  
with.

> thing locally but shortening it when publishing the feed).

Yes. Isn't this begging for mutable and non-unique ID's?

> atom:id.  The arguments against seem stronger than the arguments for

What arguments exists for relative URI's in atom:id? Maybe I haven't read  
every mail as thorough as I should, but the only I've seen so far, is  
consistency. E.g., if we allow for xml:base and relative URI's everywhere  
else in Atom, we should allow for it in atom:id as well, because it's an  
URI like every other.