Subject: Re: PaceAlternateLinkWeakening - was Managing entries/entry state

From: Henry Story <[email-masked]>
Date: Fri, 1 Apr 2005 12:15:03 +0200

On 1 Apr 2005, at 01:38, Eric Scheid wrote:
>
> On 1/4/05 9:10 AM, "Henry Story" <[email-masked]> wrote:
>
>> The value "alternate" signifies that the containing element is an  
>> alternative
>> representation of the resource identified by the IRI in the value of  
>> the href
>> attribute.
>
> You do realise you've reversed the directionality of the relationship  
> here,
> right?

Yes I thought it made the text easier to read. I did not realize anyone  
cared.

>
> IMHO, best not to introduce this ambiguity (directionality) into the  
> spec.
>
> Proposal:
> ----------------------------------------------------------------------- 
> ---
> The value "alternate" signifies that the resource identified by the  
> IRI in
> the value of the href is an alternative representation of the resource
> described by the containing element.
> ----------------------------------------------------------------------- 
> ---
>
> (yes, I know that "alternate" is a commutative bi-di relationship)

Good, but now you are reverting back to the previous relation type.

Keep in mind the question: what are we relating to what?

My answer is that we are relating a resource to a representation.
Your phrasing, as the one in the spec, is relating two resources, which  
I argued
is too strong.

I think I can get the direction back and preserving the weakening of  
the relationship
which is the core of the proposal:

Proposal
--------

replace

[[
The value "alternate" signifies that the IRI in the value of the href  
attribute identifies an alternate version of the resource described by  
the containing element.
]]

with:

[[
The value "alternate" signifies that the IRI in the value of the href  
attribute identifies a resource for which the containing element is an  
alternative representation.
]]

PS. grammarians might want to tell me of it is "of which" or "for  
which".

> e.

---

From: James Aylett <[email-masked]>
Date: Fri, 1 Apr 2005 11:45:01 +0100

> alternative representation.

The problem is that 'alternative', as used here, is not bidi: the
statement you're proposing has (for me, at least) the implication that
the most important representation is the one at the other end of the
rel='alternate' arc.

What then makes this more confusing, for me, is that the text still
says "a resource", which gives the further implication that there
might be multiple /different/ resources for which the containing
element is an alternative representation. I'd have thought it would be
clearer to have the relation going the other way, so that the
containing element is the most important representation. From its
point of view, it is - and this is its metadata.

> PS. grammarians might want to tell me of it is "of which" or "for  

I think it's "of which". It's clear either way, though, which is the
important thing :)

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Henry Story <[email-masked]>
Date: Fri, 1 Apr 2005 13:08:23 +0200

I agree with James. If feels more natural to have the arrow go from the
representation to the URI. The unjustifiable intuition would be that the
representation "knows" that it is an alternate representation of the  
resource,
but probably not vice versa. Another one would be that the link element  
is
attached to the representation, not to the uri.

In short proposal A reads "alternate" as "alternate representation of".

Proposal A
----------

replace

[[

with:

[[
the href attribute.
]]

I have changed the name of the proposal below to Proposal B to make it  
easier
to discuss.

On 1 Apr 2005, at 12:45, James Aylett wrote:
>> Proposal B
>> ----------
>   James Aylett                                                   
> xapian.org

---

From: Eric Scheid <[email-masked]>
Date: Fri, 01 Apr 2005 22:53:37 +1000

> Good, but now you are reverting back to the previous relation type.

Well, my objection is less to do with the value of 'alternate' and more to
do with the meaning of @rel, and especially with not introducing special
case semantics or ambiguities into the spec.

Take for example @rel='feed' ... what directionality does that have? Is an
entry which contains a link with @rel='enclosure' an enclosure of the
resource referenced by @href?

Remember too that @rel is extensible ... do we really want to give a false
clue in the spec that sometimes the directionality of the arc can be
reversed? 

What directionality is @rel="http://example.org/rels#next". Is the resource
identified in @href the next entry, or is the entry containing that link the
next entry, following the entry at @href?

Prior art in other specs says the relationship is from where the link is
found, and to the thing at @href.

e.

---

From: Henry Story <[email-masked]>
Date: Fri, 1 Apr 2005 15:17:31 +0200

> found, and to the thing at @href.

I think we are agreeing here.

The link is from the representation "<entry>....</entry>" to the 
resource identified by the href. That is what proposal A says, I think.

Henry

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 01 Apr 2005 19:52:19 +0200

> resource identified by the href. That is what proposal A says, I think.

Not for me...

Taking back Eric's example:
<entry>
     ...
     <link rel="http://example.org/rels#next"
           href="http://example.net/somethingelse.atom" />
     ...
</entry>
My interpretation is that "...somethingelse.atom" is the next (entry or 
whatever is defined by the @rel value herein) from the point of view of 
the entry containing the link element.

If you replace the @rel with @rel="alternate", then 
"...somethingelse.atom" is an alternate representation of "me" ("me" 
being the entry carrying the link element).

If you want to say that the entry is an alternate representation of the 
thing at @href, then (re)introduce the rev attribute: @rev="alternate", 
meaning "I am an alternate representation of the thing at @href" where 
"I" is the entry carrying the link element.

One could also think of the @rel="alternate" as a bi-di relation: "we" 
(the entry carrying the link element and the thing at @href) are 
alternate representations of the same thing, without telling which is 
the "primary" representation (maybe neither of both is, maybe the 
primary representation does not have any IRI). This means that 
@rel="alternate" has the same meaning as @rev="alternate".

Well, finally, I'll go for the last... As we are looking at the relation 
from the point of view of the entry carrying the link element, it is 
clear that the thing at @href is an alternate representation of the 
entry that we know of, but it is not defined that the "primary" 
representation might be the entry nor that the thing at @href knows of 
the entry as an alternate representation of itself, whichever is the 
"primary" representation... Well, in a few words: they are alternate 
representations of the same thing.

Same goes for @rel="related": both things are related. This is told by 
the entry carrying the link element. The thing at @href might not know 
it is related to this entry. As for "alternate", @rel="related" has the 
same meaning as @rev="related".

This is because "alternate" and "related" don't define a direction to 
the relationship.
If you bring back the "next" relationship, it defines a direction which 
is read "from the entry carrying the link element to the thing at 
@href", it defines what is the thing at @href related to the entry: it 
is the "next".

In other words, with link elements, the entry says "hey, this is an 
alternate", or "hey, this is related", or "hey, this is the next". Here, 
I use "an" for alternate and related and "the" for next because *I* have 
defined the "next" relationship as being a one-to-one.

-- 
Thomas Broyer

---

From: Henry Story <[email-masked]>
Date: Sat, 2 Apr 2005 12:15:37 +0200

On 1 Apr 2005, at 19:52, Thomas Broyer wrote:
> My interpretation is that "...somethingelse.atom" is the next (entry 
> or whatever is defined by the @rel value herein) from the point of 
> view of the entry containing the link element.

ok. <...somethingelse.atom> would be the next resource. Though I think 
the next
link was meant for feeds, and has been moved over to the API document. 
So it is
a little unfortunate to be basing your argument on an example that is 
not in the
spec, and that if it were would be attached to the feed.

> being the entry carrying the link element).

no. <...omething.else.atom> is a resource, not a representation [1].
So what you mean to say is that <...somethingelse.atom> is an alternate 
resource
of me. But that won't do since "me" is a representation. Hence what we 
have to say
is that "me" is an alternate representation of the 
<...somethingelse.atom> resource.

Now you example is also a little confusing because the type of object 
that should be
at the end of an "alternate" link, would usually not be an atom 
document, but an html
document. So let us for the sake of clarity replace 
<...somethingelse.atom> by
<...somethingelse.html> at the same time as we move from "next" to 
"alternate"

> If you want to say that the entry is an alternate representation of 
> the thing at @href, then (re)introduce the rev attribute: 
> @rev="alternate", meaning "I am an alternate representation of the 
> thing at @href" where "I" is the entry carrying the link element.

I really don't see the problem

    "<entry>...</entry>" ---alternate---> <..else.html>

think of it as a short hand for

    "<entry>...</entry>" ---alternate-representation-of---> <..else.html>

You don't have to switch the directions of the arrows for this to be 
correct. As you
see it is a relation from representation to resource.

Perhaps you are thinking "alternate-representation-of" is some causal 
relationship
and so the arrow points from the resource to the entry representation. 
Since it is
easy to think of as the resources (in http land at least) as causing 
their
representation.

But there clearly need be no such causal relation at all between the 
resource at
<..else.html> and the "<entry>...</entry>" representation. 
<..else.html> may
be a resource that only produces html representation of it.  It is none 
the
less true that the entry may be an "alternative" representation of that 
resource.
The relationship is logical not causal.

> @rel="alternate" has the same meaning as @rev="alternate".

(Again I think here you are mislead by thinking of the realtion as a 
causal one.)

One can't quite think of it as a bi-directional relationship, since the
relation is  asymmetric.

"<entry>...</entry>" ---alternate-representation-of---> <..else.html>

  works, but

<..else.html> ---alternate-representation-of---> "<entry>...</entry>"

does not. <..else.html> is not a representation, it is a resource. [1]

> Well, finally, I'll go for the last... As we are looking at the 
> relation from the point of view of the entry carrying the link 
> element, it is clear that the thing at @href is an alternate 
> representation of the entry that we know of,

yes

> but it is not defined that the "primary" representation might be the 
> entry nor that the thing at @href knows of the entry as an alternate 
> representation of itself,

Here we are!
As I said above this is not a causal relationship. We are not saying 
that
the <entry>...</entry> representation is "known" by the hrefed 
resource, that it
can produce it, or anything like that. We are just saying that it is an 
alternative
representation (alternative is happily quite vague) of the remote 
resource.

> whichever is the "primary" representation... Well, in a few words: 
> they are alternate representations of the same thing.

"They" meaning what?
<...else.html> and "<entry>...</entry>" are not both representations 
only the second
one is.

what you mean is that <...else.html> has many representations. Some of 
these are html
ones that it produces, others are atom ones that are produced by 
others. We have something
like this

<...else.html> ---representation---> "<html><body>...</body></html>"
       |-----------representation---> "<xhtml><body>...</body></xhtml>"
       |
       |-----------representation---> "<entry>...</entry>"

If we now distinguish between cause and uncaused ones (call crep and 
rep)

<...else.html> ---crep---> "<html><body>...</body></html>"
       |-----------crep---> "<xhtml><body>...</body></xhtml>"
       |                           ^
       |                           |
       |                        similar
       |                           |
       |-----------rep---> "<entry>...</entry>"

now "similar" is indeed a bi-directional representation. And I think you
are speaking of the similar relation just illustrated.

So to summarize the whole argument in a graph:

we have three alternate relations
   -spec6:alternate is currently what the spec says
   -A:alternate is the one of my proposal A
   -tom:alternate is the relation you mention above between two 
representations.
         Notice that I should really draw tom:alternate as relation 
between
         the "<entry>...</entry>" representation and each one of the 
"<html>..." and
         "<xhtml>..." representations. The problem is that it would not 
be helpful
         to express a relation between the different representations as 
we don't have
         a good handle (name) on them.

So as I explained in previous posts, the problem with spec6:alternate 
is that the
relation is too strong.
     In the graph I show some nodes in yellow and others in green.  The 
green nodes
are grouped together because they represent a later stage in time when 
<..else.html>
was displaced to <displaced.html>. As a result perhaps a few links had 
to
be changed in the html and xhtml, and so <displaced.html> has different 
html and xhtml
representations. It also comes with a different "<entry>...</entry>" 
representation
(which has a different timestamp for example) and a different 
A:alternate relation.
But the id of both "<entry>..." representations is the same.
	Now to say that we want a spec6:alternate relation would say that the 
<urn:uuid..>
resource is an alternate to <..else.html>, which it is not really. That 
would seem to
say that the later "<entry>..." representation is also in the same 
sense a spec6:alternate
to <else.html>. I think we are much clearer by sticking to A:alternate.

> it is related to this entry. As for "alternate", @rel="related" has 
> the same meaning as @rev="related".

rel:related is a different relation. I have not checked carefully what 
I think of it yet.
But there is nothing a priori wrong with relations that relate the id 
of the entry to
another resource. We just have to ask carefully if that is what the 
authors of the spec
really intended.

> If you bring back the "next" relationship, it defines a direction 
> which is read "from the entry carrying the link element to the thing 
> at @href", it defines what is the thing at @href related to the entry: 
> it is the "next".
>
> alternate", or "hey, this is related", or "hey, this is the next". 
> Here, I use "an" for alternate and related and "the" for next because 
> *I* have defined the "next" relationship as being a one-to-one.

I think I have made my point as clearly as I can now. Let me know if 
that explanation
has helped.

Henry Story
http://bblfish.net/blog/

[1] http://www.w3.org/TR/webarch/#id-resources

---

From: Eric Scheid <[email-masked]>
Date: Sat, 02 Apr 2005 22:16:52 +1000

On 2/4/05 8:15 PM, "Henry Story" <[email-masked]> wrote:

> no. <...omething.else.atom> is a resource, not a representation [1]. So what
> you mean to say is that <...somethingelse.atom> is an alternate resource of
> me.

Firstly, why is "<html>...</html> a representation, while "<entry>
...</entry>" not a representation?

Secondly ... "alternate resource" ... wha?

A resource is an abstract thing, reified by representations, right?

e.

---

From: Henry Story <[email-masked]>
Date: Sat, 2 Apr 2005 15:03:09 +0200

On 2 Apr 2005, at 14:16, Eric Scheid wrote:
>> So what

I don't understand. Are you asking me? I am asserting that 
"<html>..</html>" and
<entry>...</entry> are both representations.  I have put all 
representations in
rectangles in the attached diagram of my previous email, just to make 
this point.

> Secondly ... "alternate resource" ... wha?

Argh. I was trying to show what was wrong with Thomas' argument. That 
is why that does not
make sense. If you read on you will see that I criticize his position 
for that reason.

> A resource is an abstract thing, reified by representations, right?

Something along those lines yes.

Henry Story

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 03 Apr 2005 00:06:49 +0200

Henry Story wrote:
> the next link was meant for feeds, and has been moved over to the API
 > document.

This is not the same "next" relationship...

> So it is a little unfortunate to be basing your argument on an example
 > that is not in the spec, and that if it were would be attached to the
 > feed.

Well, feeds also carry link elements with a possible "alternate" value 
for their rel attribute...

> resource of me. But that won't do since "me" is a representation. Hence
 > what we have to say is that "me" is an alternate representation of the

Ok, I finally understand what you mean...

Actually, the problem is applying "alternate version" to "resource" 
rather than "representation of a resource".

What about:
[[
The value "alternate" signifies that the IRI in the value of the href 
attribute identifies a resource whose representations are an alternate 
version of the resource described by the containing element.
]]

>    "<entry>...</entry>" ---alternate-representation-of---> <..else.html>

But the former one says (fmpov) something like "...else.html" is an 
alternate of "entry" while the latter says "entry" is an alternate 
(representation) of "...else.html".
You are switching the directions of the meanings (ok, without switching 
the directions of the arrow... that's something like active/passive 
forms in grammar)

> Here we are!
> As I said above this is not a causal relationship. We are not saying that
> the <entry>...</entry> representation is "known" by the hrefed resource, 
> that it can produce it, or anything like that. We are just saying that it
 > is an alternative representation (alternative is happily quite vague) of
 > the remote resource.

yes

> only the second one is.

The problem with the web-arch "language" is that once you print a web 
page (a representation of a resource), it (the printed sheets) is not 
the same resource any more (if I understand correctly). Though the still 
are resources/representations/call-how-you-want of the same "thing".

> ones that it produces, others are atom ones that are produced by others. 
> We have something
> like this
> 
> If we now distinguish between cause and uncaused ones (call crep and rep)
> 

Yes, but why not call it "alternate"?

-- 
Thomas Broyer

---

From: David Nesting <[email-masked]>
Date: Sat, 2 Apr 2005 16:57:48 -0600

> Why isn't this requirement a "may" instead of a "must"? I can see having
> a link with rel=alternate if indeed a alternate version does exist. It
> does not make sense to put in some something misleading if an alternate
> does not exist.

I recently sought out and joined this list precisely because I wanted
to see if this issue had been addressed.  I don't think it's reasonable
to assume there will always be an alternate version of a feed.  If this
remains a "MUST", I have no choice but to honor this by using a dummy
value for an "alternate" page, since I may not have an alternate.

Without any background, it seems to me that the goal here is to "require"
a link *back* to an HTML page that is presumed to have provided an
"alternate" link to this Atom resource.  This of course assumes that an
HTML or non-Atom version actually exists, and that resource is independent
of the Atom resource.  (Consider that I may have an HTML version, but
it could be derived from the Atom version using XSLT.  It's not accurate
to consider this an "alternate" when it's an XML style sheet involved.)

I couldn't find any reference to this issue in the mailing list, aside
from this (thankfully recent) thread.  If it's been addressed before,
could someone point me to the thread in the list archives?

David

--
 == David Nesting WL7RO Fastolfe [email-masked] http://fastolfe.net/ ==
 fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882  C41F 3065 57D9 832F AB01

---

From: Sam Ruby <[email-masked]>
Date: Sat, 02 Apr 2005 21:22:49 -0500

> could someone point me to the thread in the list archives?

I can point you to the threads (yes, this has come up mutiple times).

Do you, today, produce an RSS feed?  If so, what version of RSS?  Is it 
valid?

I've run a feedvalidator for years.  Every version of RSS has required 
this link.  I've *never* heard anybody complain about this in the 
context of any version of RSS.  It puzzles the bejeebers out of me why 
this issue is only brought up in the context of Atom.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Sun, 03 Apr 2005 10:14:33 +0900

Of course I'm also for making an alternate link for a feed a
MAY rather than a MUST.

Regards,   Martin.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 03 Apr 2005 14:57:29 +0200

> Of course I'm also for making an alternate link for a feed a

+1

I don't see any advantage at all in forcing an alternative representation  
to exist, and I have yet to see a real argument[1] why such an alternative  
representation must exist .

___
[1] "simplifies validation", and "causes problems for some newsreaders"  
are not arguments.

-- 
Arve Bersvendsen  -  http://virtuelvis.com/

---

From: James Aylett <[email-masked]>
Date: Sun, 3 Apr 2005 14:45:59 +0100

> this issue is only brought up in the context of Atom.

Speaking personally, I would never have complained about it in the
context of RSS because RSS is such a fragmented mess. It comes up in
the context of Atom because Atom is trying to be unambiguous and
helpful.

If MUST is vastly preferable for user agent implementors, then IMHO
there should at least be an explanation of what to do when you can't
generate an alternate repr (for instance: you may not have enough
resource to build an alternate version when you know that alternate
version won't be used). Given that the spec currently deliberately
backs off on implementation usage (and rightly so), but marks round
tripping as a SHOULD (but puts these in different sections with no
cross-linking), I feel that a tiny bit (not sarcastic - literally a
tiny bit) more guidance for feed producers would be helpful.

James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 3 Apr 2005 17:37:08 +0200

* Sam Ruby <[email-masked]> [2005-04-03 04:30]:
> Every version of RSS has required this link.  I've *never*
> heard anybody complain about this in the context of any version
> of RSS. It puzzles the bejeebers out of me why this issue is
> only brought up in the context of Atom.

My guess is that it’s because Atom actually tries to define a
content model that allows more than just title, link,
description. Multiple links and payloads with different semantics
each are supported and, if that’s what appropriate for a
particular case, encouraged.

So I think it’s no wonder that people are seeing Atom as a
transport for things they might have either not done with RSS, or
inclued fudged links for.

Examples that suggest a need for MAY certainly exist: I have one.
I run a scraped feed[1] for the Slackware news, where the content
from a single web page is scraped divided into multiple separate
entries.

[1] http://plasmasturm.org/feeds/

These don’t appear individually on pages of their own, so it
would be most logical to omit the alternate representation link
entirely. An alternate representation MUST be given, however, so
I use the same link as an for each entry as I use for the feed
itself. Cruft.

Regards,
-- 
Aristotle
“If you can't laugh at yourself, you don't take life seriously enough.”

---

From: David Nesting <[email-masked]>
Date: Sun, 3 Apr 2005 12:27:40 -0500

> the context of Atom because Atom is trying to be unambiguous and

This is my view as well.

> generate an alternate repr

I was able to locate a previous thread where this issue was discussed, but
the thread appeared to peter out before this question was asked/answered.

Consider for a minute these two scenarios where one might want to
use Atom:

1. Where the Atom resource is the only HTTP resource representing that
   list of syndicated content.  I MAY have an HTML version that is
   derived from the Atom one using XML style sheets, but I might not.
   That's my call.

2. Where the Atom resource itself isn't even delivered by HTTP.  I may
   place it in a message delivered via SMTP, or in my own application
   protocol.  Maybe I'm multicasting it to an application in my
   organization.  I may be referencing content that *is* accessible on
   the web, but my actual syndication list isn't.

At a minimum we need to specify what implementers must do when no
alternate version exists.  Even if that means specifying "about:blank"
as the alternate URL, it should at least be documented.  That way,
implementations that choose to do so can at least make an educated
decision about whether the value of that alternate link is meaningful
or just a dummy value.

If we can't or don't want to document this in the specification, maybe all
we need is some unofficial, non-binding agreement now that implementations
can CHOOSE to follow if they want.  Maybe someone can whip up a persistent
URI that can either stand for (or even deliver a message saying) "no
alternate exists"?  I suggested about:blank earlier, but maybe something
delivered via HTTP (a la http://www.example.com/) might be appropriate?
Maybe "x-atom:no-alternate-uri"?  Implementations that abide solely by the
specification and aren't aware or choose not to follow this convention
only run the risk of allowing users to follow broken or useless links,
which is exactly the situation we have today anyway.

I've used RSS in some unofficial capacity in some internal applications.
Maybe the regurgitated specifications I had my hands on were just
incomplete or inaccurate, but none of these had any "alternate"
link requirement.  Many of my own feeds would have had "alternate"
links with dummy values if I had been more aware of this requirement.
So just because nobody complained about the artificial constraint in
RSS doesn't mean the constraint is legitimate.  I've found that every
RSS reader or RSS "consumer" application handled these feeds without
a problem.  I should point out that the reason I am interested in Atom
is to take this to the "next level" in my organization and actually
back an IETF standard syndication format for these purposes.  The RSS
implementations have just been proofs of concept at this point.

Thanks for your time.

David

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Apr 2005 10:51:50 -0700

OK, I observe a lot of people speaking up for <link>-less feeds, 
presenting some plausible use cases.  I observe only Sam speaking up 
for retaining the compulsory link.  I observe at least one person 
speaking up saying "if it's compulsory I'll generate a fake one", which 
seems significant to me.

I'm starting to smell possible consensus; are there more people here 
who agree with Sam?  If so, speak up.  Also, if dropping <link> is 
going to break something (haven't heard that yet), someone should 
please point that out.

Apologies in advance if you already have spoken on this and I missed 
it. -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 3 Apr 2005 15:06:26 -0400

On Apr 3, 2005 1:51 PM, Tim Bray <[email-masked]> wrote:
> who agree with Sam?  If so, speak up.  

I agree with Sam, +1 to the required <link>. The argument that you 
can't have an HTML representation are weak, since *I* can 
generate one for your feed,  whether you like it or not, ala:

   http://www.rss2html.com/

I can also generate an XSLT sheet that transforms Atom into
HTML then use the W3C XLST service to transform
an Atom feed into HTML:

   http://www.w3.org/2001/05/xslt

Now the generated HTML may not be optimal but I hope this
shows that barrier to generating an HTML 'alternate' is
not onerous, and that the link should remain a MUST.

   Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Henry Story <[email-masked]>
Date: Sun, 3 Apr 2005 21:21:26 +0200

Let me skip right to the core of your answer.

> version of the resource described by the containing element.

The question is here: what is "the resource described by the containing 
element" referring to?
As I argued in a previous post to this thread [1] my belief is that 
this is the resource
named by the id of the entry. I did not make that aspect of my thinking 
visible in the graph
attached to my previous mail [2] so I will now, by adding the  
representation relations
(named "repres") in the following graph:

The "<entry>..." in green and in yellow are representation of the 
<urn:uuid:1225...> resource,
just as the yellow "<html>..." and "<xhtml>..." representations are 
representation of the
<else.html> resource, and the green "<html>..." and "<xhtml>..." 
representation are of the
<displaced.html> resource.

Now if I look at your definition above you are relating two resource 
the same way the
current spec does. Say we had an "alternate" link on the green 
"<entry>...", then your
definition would be relating the <urn:uuid:1225...> resource to the 
<displaced.html>
resource.

But what I don't understand is that you are saying the representations 
of <displaced.html>
namely the green html and xhml representations are alternate versions 
of <urn:uuid:1225>.
How can representations be alternate versions of a resource?

Perhaps you mean that they are alternate versions of the 
representations described by the
<urn:uuid:1225...>?

[1] http://www.imc.org/atom-syntax/mail-archive/msg13940.html
[2] see: http://www.imc.org/atom-syntax/mail-archive/msg13959.html

>> ok. <...somethingelse.atom> would be the next resource. Though I 
>> think the next link was meant for feeds, and has been moved over to 
>> the API
> > document.
>

yes. But it ends up being taken that way. So in the end things get a 
little confusing.

>> So what you mean to say is that <...somethingelse.atom> is an 
>> alternate resource of me. But that won't do since "me" is a 
>> representation. Hence
   [sniped and copied to head of mail]
> You are switching the directions of the meanings (ok, without 
> switching the directions of the arrow... that's something like 
> active/passive forms in grammar)

Perhaps we should first get to agree on the arrows we want, and then 
try to work out
how the english is going to express the arrows we want. I think we both 
agree on the
direction of the arrows.

>> resource, that it can produce it, or anything like that. We are just 
>> saying that it
> the same resource any more (if I understand correctly). Though the 
> still are resources/representations/call-how-you-want of the same 
> "thing".
>
>> what you mean is that <...else.html> has many representations. Some 
>> of these are html

no problem. In the graph I ended up calling it tom:alternate. [2]

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Sun, 03 Apr 2005 21:30:07 +0200

> not onerous, and that the link should remain a MUST.

This does not have to do with the _ease_ of generating an HTML  
"alternate", it has to do with the usefulness of generating one. Atom may  
well work as (and/or be extended to be) a generic data interchange format  
for certain types of applications where the alternate web version is  
clearly not useful. Think mail.

-- 
Arve Bersvendsen

---

From: Graham <[email-masked]>
Date: Sun, 3 Apr 2005 20:45:21 +0100

> not onerous, and that the link should remain a MUST.

So do you have an argument here as to why it should be required? All 
I'm seeing is that it's easy to workaround when the publisher omits it.

Graham Parks

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 3 Apr 2005 22:01:53 +0200

* Joe Gregorio <[email-masked]> [2005-04-03 21:15]:
> HTML then use the W3C XLST service to transform an Atom feed
> into HTML:

That is true, but how is the result of an operation that depends
on the feed itself an alternate representation in any meaningful
sense?

Regards,

---

From: James Aylett <[email-masked]>
Date: Sun, 3 Apr 2005 21:47:54 +0100

On Sun, Apr 03, 2005 at 03:06:26PM -0400, Joe Gregorio wrote:

> can't have an HTML representation are weak, since *I* can generate
> one for your feed, whether you like it or not.  Now the generated
> HTML may not be optimal but I hope this shows that barrier to
> generating an HTML 'alternate' is not onerous, and that the link
> should remain a MUST.

I think this highlights why I oppose MUST: what on earth is the
utility of this alternate to the end user? The /only/ thing it seems
to do is to provide a way of moving the view of the feed from the Atom
client (which may be able to take advantage of the intrinsic
structure, plus extension metadata) to an HTML client (probably a web
browser), which probably can't do quite as much with it, and certainly
can't do more in the case where the HTML is auto-generated from the
Atom. Which, to the person sitting at the computer, doesn't strike me
as much use.

And since the spec doesn't touch user agent handling of the
rel='alternate' (rightly), even if that were a desirable thing to do,
it won't work with all feeds, since I am in my rights (for instance)
to <atom:link rel='alternate' type='image/png' .../>, an artistic
interpretation of the feed as if it were a swallow.

The spec doesn't tell us precisely enough what alternate is for it to
make sense as a MUST, in my view. Further, I don't think that it is
practical to try to get a precise enough wording for MUST to become
useful; even if it was, it would probably require placing restrictions
on how the Atom clients use the link, which we don't do at the moment
and in IMHO we should not even consider.

I think the argument that it is trivial to produce an HTML
representation of the data in the Atom feed actually reinforces my
point here - if the user agent actually NEEDS an HTML version of the
data, and a link to one isn't supplied, it can generate one
itself. It'll have to do that even with the current wording, since I
can quite happily satisfy the MUST requirement with a non-HTML
version. (Something which I believe can't be done legally with RSS, or
at least not all the different breeds. Not that that matters.)

James

---

From: David Nesting <[email-masked]>
Date: Sun, 3 Apr 2005 15:49:38 -0500

> generate one for your feed,  whether you like it or not, ala:

OK, I have Atom documents stored in the following places:

1. An attachment (or the content body) of an e-mail message
2. In an Oracle database behind a firewall
3. In an LDAP attribute, also behind a firewall
4. On a key chain hard drive
5. Typed out on a sheet of paper

What URL can I use to refer to each of those?  The key chain drive usually
shows up as drive E:, if that helps.  For simplicity, let's assume the
sheet of paper can be stored on/in a flatbed scanner.

>    http://www.w3.org/2001/05/xslt

Let's say I care about providing an HTML representation for my data.
XML lets me embed an XML stylesheet into the XML data itself.  So now
I have a completely self-contained Atom resource that user agents can
transform into HTML without needing a link to any external resource.
Even if this could be represented with a URI, why would I want to specify
an alternate version when the first version has everything I could want?

All I hear are ways *some* Atom documents can be given alternate versions.
I still haven't heard WHY that should be required, other than "because
RSS does it."  Why does RSS require it?  Maybe we can start there.

David

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 03 Apr 2005 23:02:42 +0200

Henry Story wrote:
> Perhaps you mean that they are alternate versions of the representations 
> described by the <urn:uuid:1225...>?

That's it! (I think...)

Now that we agree, I let you use the web-arch to describe it.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Apr 2005 17:22:46 -0400

> Of course I'm also for making an alternate link for a feed a

I'm in favor of keeping it a MUST, but I could live with it becoming a 
SHOULD. As Sam says, all versions of RSS have made it a requirement. 
Feeds without a link will probably break some clients, so you better 
know what you're doing. OTOH, there have been some persuasive arguments 
for making it optional.

If we change it, SHOULD seems like the right way to go: "the distinction 
between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to stupid 
implementors."[0] :)

Robert Sayre

[0] http://lists.w3.org/Archives/Public/ietf-http-wg/2005JanMar/0088.html

---

From: Henry Story <[email-masked]>
Date: Sun, 3 Apr 2005 23:56:03 +0200

On 3 Apr 2005, at 23:02, Thomas Broyer wrote:
>> representations described by the <urn:uuid:1225...>?
>
> That's it! (I think...)
>

Ok. So let us try the slightly clumsy (to be improved later) definition

What about:
[[
The value "alternate" signifies that the IRI in the value of the href 
attribute identifies a resource whose representations are an alternate 
version of the representation described by the resource described by 
the containing element.
]]

and let us look at the application of this definition to the example of 
our graph above.

Here you see that the <urn:uuid:1225...> does not have 1 
representation, but two representations: the yellow and the green 
"<entry>..." representations. One of these
representations (the yellow, older one) had a link to <else.html>, 
while the other
(the greener, newer one) had a link to <displaced.html>.
    So according to your definition the green tom2:alternate arrow (the 
one that arises
from the information in the green entry) says is that these two yellow 
and green entry
representations are alternates of the green "<xhtml>..." and 
"<html>..." representations.
	But that is not quite what we want to say, since that would make the 
older yellow
"<entry>..." representation an alternative of the newer green html and 
xhtml representations.
These might have changed only a little during the displacement, but 
they may also have changed
a lot more. This just does not seem quite right.
     Now I can hear you think (amazing powers that I have :-) that what 
you really mean is
that the green entry representation alone (not the older yellow one) is 
an alternate version
of the representation of the <displaced.html> resource. But if you mean 
to say that, then
why bring <urn:uuid:1225...> the id of the entry into the picture at 
all?

Let us just cut it out, since the link construct can indexically refer 
to the representation
in which it is located.

[[
The value "alternate" signifies that the IRI in the value of the href 
attribute identifies a resource whose representations are an alternate 
version of the containing element.
]]

Now I think we have another way of saying what I meant by the 
A:alternate relation.
Which of the phrasings is better, the one above or

[[

is now a matter of which one is clearer. But I think we are describing 
the same relation.

Henry Story

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Apr 2005 15:03:08 -0700

> I'm seeing is that it's easy to workaround when the publisher omits 

Agreed.  Joe, that wasn't very convincing.  I repeat, we've seen 
several very believable use-cases for why someone might want this, and 
no good arguments (that I can remember) that it would break anything.  
Sam has pointed out that no previous version of RSS has done this, 
which is a reasonable argument; except for we have use-cases, and 
nobody's shown that the cost is non-zero. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Apr 2005 18:30:36 -0400

Tim Bray wrote:

> Agreed.  Joe, that wasn't very convincing.  I repeat, we've seen several 
> very believable use-cases for why someone might want this, and no good 
> arguments (that I can remember) that it would break anything.  Sam has 
> pointed out that no previous version of RSS has done this, which is a 
> reasonable argument; except for we have use-cases, and nobody's shown 
> that the cost is non-zero. -Tim

I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss and 
removed the <link> element. This absence caused Bloglines to behave oddly.

Robert Sayre

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Mon, 04 Apr 2005 00:46:12 +0200

> removed the <link> element. This absence caused Bloglines to behave  

In what sense?

Please be aware that the absence of <link /> is not something I think  
you'd usually see on the public web, anyway.

-- 
Arve

---

From: Graham <[email-masked]>
Date: Sun, 3 Apr 2005 23:50:25 +0100

On 3 Apr 2005, at 11:30 pm, Robert Sayre wrote:

>> arguments (that I can remember) that it would break anything.  Sam 
>> has pointed out that no previous version of RSS has done this, which 
>> is a reasonable argument; except for we have use-cases, and nobody's 
>> shown that the cost is non-zero. -Tim
>
> I copied Tim's feed to http://franklinmint.fm/2005/04/03/ongoing.rss 
> and removed the <link> element. This absence caused Bloglines to 
> behave oddly.

I copied Tim's feed and renamed the description elements to "summary" 
and the items to "entry". This caused Bloglines to behave oddly*.

(* actually it didn't, but that's not the point)

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Apr 2005 18:53:28 -0400

>> and  removed the <link> element. This absence caused Bloglines to 

Sorry, I was a little unclear. Bloglines made "Ongoing" a hyperlink, but 
it linked to the page I was already looking at without the navigation 
frame.

> you'd usually see on the public web, anyway.

I see Graham has written about "the point", which is that existing UIs 
often assume the availability of a link from the feed. This is a SHOULD, 
  with stern warnings, minimum.

Robert Sayre

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Apr 2005 15:55:36 -0700

We are creating a new protocol. We don't expect any current reader to 
behave well with it before it is done.

Quoting from RFC 2119, which is what we are using to define MUST and SHOULD:

6. Guidance in the use of these Imperatives

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.

Why is the alternate link "actually required for interoperation or to 
limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)"?

It seems like a perfect candidate for MAY, like most of the rest of the format.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 04 Apr 2005 00:04:41 +0100

> that the cost is non-zero. -Tim

The top level feed stuff doesn't make a lot of sense to me. That 
@alternate is mandatory while @self and atom:id are not isn't very 
convincing either:

  atom:link[@rel='alternate'] : MUST
       atom:link[@rel='self'] : SHOULD
                      atom:id : MAY	

You can't have a useful discussion about @alternate without talking 
about @self or atom:id.

Thus: I'm -1 to downgrading @alternate unless @self is lifted to MUST or 
atom:id is lifted to MUST. If either are lifted to must I'm 0 on 
downgrading @alternate. At that stage @alternate doesn't matter a whole lot.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Apr 2005 16:09:44 -0700

> and removed the <link> element. This absence caused Bloglines to 

Well, yeah, but when they do the half-hour's coding it's going to cost 
them to start supporting Real IETF Atom 1.00 (tm), they can do an extra 
3 minutes and if there's no <link>, they don't make the subscription 
clickable.  Works fine in NetNewsWire btw. -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 3 Apr 2005 19:11:58 -0400

> downgrading @alternate. At that stage @alternate doesn't matter a whole lot.

For me David Nesting's example of an Atom document as 
an email attachment was the most convincing that @alternate
doesn't need to be a MUST. 

I agree here with Bill and personally prefer to see atom:id lifted
to a MUST.

    -joe

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Apr 2005 16:13:55 -0700

> It seems like a perfect candidate for MAY, like most of the rest of 

I think <link rel="self"> is a SHOULD, to address auto-subscriptions, 
one of the current #1 RSS pain points, perceived by users as a failure 
to interoperate. -Tim

---

From: Tim Bray <[email-masked]>
Date: Sun, 03 Apr 2005 16:12:22 -0700

Just so everyone's clear: what we're arguing about is <link 
rel="alternate"> on <atom:feed>, not on <atom:entry>.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Apr 2005 19:16:55 -0400

Tim Bray wrote:

> clickable.  

I doubt they've never encountered a feed without a link. Why do you 
think they didn't fix it? For example, they will accurately parse a feed 
that sends a unix timestamp instead of an RFC822 date.

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Sun, 03 Apr 2005 19:50:35 -0400

/ "Arve Bersvendsen" <[email-masked]> was heard to say:
| n Sun, 03 Apr 2005 03:14:33 +0200, Martin Duerst
| <[email-masked]>  wrote:
|
|> Of course I'm also for making an alternate link for a feed a
|> MAY rather than a MUST.
|
| +1
|
| I don't see any advantage at all in forcing an alternative
| representation  to exist, and I have yet to see a real argument[1] why
| such an alternative  representation must exist .

I have to vote +1 on this too. Twice now I've wanted to generate feeds
(once for Subversion change logs and once for the 404s produced by my
web server) where I thought the manditory alternate link was
inpractical or impossible.

For the Subversion case, I actually generated HTML pages so that I
could point to them, but that's only because it felt geeky enough to
be entertaining.

For the 404 case, I use the 404 link as the alternate representation
and that's just...pointless.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Human felicity is produced not so much
http://nwalsh.com/            | by great pieces of good fortune that
                              | seldom happen, as by little advantages
                              | that occur every day.--Benjamin Franklin

---

From: Norman Walsh <[email-masked]>
Date: Sun, 03 Apr 2005 19:51:03 -0400

/ Robert Sayre <[email-masked]> was heard to say:
| Martin Duerst wrote:
|> Of course I'm also for making an alternate link for a feed a
|> MAY rather than a MUST.
|
| I'm in favor of keeping it a MUST, but I could live with it becoming a
| SHOULD. As Sam says, all versions of RSS have made it a requirement.
| Feeds without a link will probably break some clients, so you better
| know what you're doing. OTOH, there have been some persuasive
| arguments for making it optional.
|
| If we change it, SHOULD seems like the right way to go: "the
| distinction between 'SHOULD' and 'MUST' in RFC2119 doesn't apply to
| stupid implementors."[0] :)

SHOULD works for me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | In a universe of electrons and selfish
http://nwalsh.com/            | genes, blind physical forces and
                              | genetic replication, some people are
                              | going to get hurt, other people are
                              | going to get lucky, and you won't find
                              | any rhyme or reason in it, nor any
                              | justice.--Richard Dawkins

---

From: Eric Scheid <[email-masked]>
Date: Mon, 04 Apr 2005 12:59:57 +1000

> downgrading @alternate. At that stage @alternate doesn't matter a whole lot.

-1: the reasons against @self MUST are similar to the reasons against
@alternate MUST.

I'll be happy with:

    self:       MAY
    alternate:  MAY
    id:         SHOULD

or possibly even:

    self:       SHOULD
    alternate:  SHOULD
    id:         MUST

e.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Apr 2005 20:32:25 -0700

Not to pick on Eric; others have said things along the lines of:

>     id:         MUST

This isn't a negotiating game. We have to have technical reasons for 
our assigning requirements levels.

To repeat the relevant section from RFC 2119 (which is only two pages 
long, really):

What is the technical reasons for the SHOULDs and MUSTs? Where is the 
interoperability issues within the protocol (not with readers that 
don't know what the protocol looks like)? What are the potentials for 
causing harm? I'm not saying there are none; I'm saying let's choose 
our levels based on what we are supposed to be choosing from.

--Paul Hoffman, Director

---

From: Robert Sayre <[email-masked]>
Date: Sun, 03 Apr 2005 23:59:53 -0400

Paul Hoffman wrote:

> interoperability issues within the protocol (not with readers that don't 
> know what the protocol looks like)? What are the potentials for causing 
> harm? I'm not saying there are none; I'm saying let's choose our levels 
> based on what we are supposed to be choosing from.

If none of them are MUST, there is no social recourse when tracking down 
problems or seeking social understanding. Where did this feed come from? 
Who makes alternates? What's this all about?

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Mon, 04 Apr 2005 14:25:16 +1000

> Not to pick on Eric; others have said things along the lines of:

no offence taken.

> our assigning requirements levels.

I can't think of any MUST reasons for link[@rel='self'] or
link[@rel='alternate'].

For atom:id I can see how being able to clearly and unambiguously identify a
feed would help us avoid requesting feeds from different URIs only to get
the same information (that falls under "avoiding retransmission", right?).

I can think of only one SHOULD reason for link[@rel='self'], which is the
auto-subscribe interoperability problem with browsers. *

hmmm..

    link[@rel='alternate']  =   MAY
    link[@rel='self']       =   SHOULD
    id                      =   SHOULD

e.

ps. I think it would be prudent to put the reason why something is a SHOULD
in the spec itself.

pps. I'm inclined to go the same way with atom:entry/atom:link's

---

From: Henry Story <[email-masked]>
Date: Mon, 4 Apr 2005 11:20:23 +0200

Rereading my mail I found that I was perhaps not as clear as I could be.
So here are a few improvements.

> version of the representation described by the resource described by 

In this new graph I have now shown the consequence of the relation 
defined above
as little arrows between the entry representations and the html and 
xhtml representations.
It is not clear exactly which of the green arrows should be named 
tom2:alternate, the
one between the entry id and the displaced resource or the little ones 
which relate the
representations. In any case the argument still holds: we have a 
relation that I had
argued before is too strong. It relates things we don't really want to 
relate, namely
the yellow entry and the green representations.

> [snip]

> that the green entry representation alone (not the older yellow one) 
> is an alternate version
> of the representation of the <displaced.html> resource. But if you 
> mean to say that, then

let me call the following relation tom:alternate

> is now a matter of which one is clearer. But I think we are describing 

On closer thought we are not. The intent of tom:alternate is to 
describe a relation between
representations, shown in the diagram below as little unlabeled green 
arrows. Just as in the
previous definition it is not clear whether the definition above 
relates the <entry>
representation and the <displaced.html> resource, or whether it is 
trying to identify the
consequences of the relation (the unlabeled arrows).

There is the question I had brought up in an earlier e-mail [1] as to 
whether the alternate
relation relates a representation and a resource or two 
representations. I think
that the A:alternate relation is  less ambiguous at present and so 
preferable.

Henry Story
http://bblfish.net/blog/

[1] http://www.imc.org/atom-syntax/mail-archive/msg13897.html

---

From: James Aylett <[email-masked]>
Date: Mon, 4 Apr 2005 10:34:23 +0100

+1

James

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 04 Apr 2005 13:04:18 +0100

> -1: the reasons against @self MUST are similar to the reasons against

I don't understand. How are these alike?

cheers
Bill

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 04 Apr 2005 13:25:54 +0100

> I can't think of any MUST reasons for link[@rel='self'] or

Then let me try and help you with that.

I can think of long nights tracking down data because I didn't have way 
to hand systems an identifier.

In the Atom 06 format there are 3 things potentially acting as 
identifiers for the source of an Atom feed. The one that going by the 
commonsense name least likely to be considered a meaningful identifier 
is mandatory. Sorry to offend anyone in this WG, but that's absurd. 
Never mind that we're creating an arbitrary distinction between feed ids 
and entry ids.

I have very strong opinions on this: too many identifiers cause problems 
when it comes to system and data management -worst scenario in terms of 
cost are too many unreliable identifiers. For a pure client/server 
newsreader case I can see how this might not bite so much. For anyone 
passing Atom along a processing chain or heaven forbid, something like a 
SEDA system, not having assured easy to find identifiers is a cost.

Being able to rely on the presence of an (ideally, single) identifier is 
a management win and an interop win. It is one of the reasons Web based 
systems are easy to run. Not having such a thing for Atom feeds ensures 
people will have to invent it especially for non-HTTP scenarios. The 
upfront cost of mandating either self or id is so small versus the 
benefit of being able to shout out something's name when something goes 
awry I can't believe we're even having this discussion.

Anyway I've made my position clear at this point. Please make id or self 
mandatory.

[Please don't argue on the basis that URL links aren't identifiers or 
names and shouldn't be treated as such; it's de jure Web architecture 
that they are.]

cheers
Bill

---

From: Eric Scheid <[email-masked]>
Date: Mon, 04 Apr 2005 23:02:36 +1000

> Anyway I've made my position clear at this point. Please make id or self

atom:id then, since atom:link[@rel='self'] could change at any point in
time, and mutability is not a good attribute of an identifier.

e.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 04 Apr 2005 22:58:17 +1000

> I don't understand. How are these alike?

one reason against @rel='self' is that the feed may not be retrievable at
all (being delivered some other way)

one reason against @rel='alternate' is that there may not be any web
retrievable resource.

e.

---

From: Elias Torres <[email-masked]>
Date: Sun, 3 Apr 2005 21:50:20 -0400

I do think also that there are plenty of use cases suggesting that
alternate might not be always available. However in that context where
there's no feasible alternate, it would be extremely useful to know
you can count on atom:id. If not, what else can you rely on to track
your "content" as it flows from system to system without an alternate.
I have not been following atom-syntax for a while, but are there any
other elements that could be used if no alternate was not found? I
think this is the reason why Sam has never seen anybody complain about
link because, it doubles as id as well, but since we have a clear
separation in atom, either or both might be good to be specified.

Just my two cents.

Elias Torres

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 4 Apr 2005 09:43:22 -0400

+1

Of course, if link@alternate is not the identifier and it falls to atom:id
then we may end up having to add more verbage to the spec. For example,
today some feeds are full-content, others are abbreviated. If I
produce both kinds
of feeds, do I use the same atom:id for both? What if one feed is delivered via 
email and the other via HTTP, should they both use the same atom:id?

   -joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Apr 2005 07:31:51 -0700

At 11:59 PM -0400 4/3/05, Robert Sayre wrote:
>If none of them are MUST, there is no social recourse when tracking 
>down problems or seeking social understanding. Where did this feed 
>come from? Who makes alternates? What's this all about?

Good, we're making progress. You're aiming at the "to limit behavior 
which has potential for causing harm" part of 2119.

I'm fine with making one of them a MUST for that reason. atom:id 
seems like the one that would most help tracking down problems, yes?

At 4:13 PM -0700 4/3/05, Tim Bray wrote:
>I think <link rel="self"> is a SHOULD, to address 
>auto-subscriptions, one of the current #1 RSS pain points, perceived 
>by users as a failure to interoperate. -Tim

Sounds good to me.

>ps. I think it would be prudent to put the reason why something is a SHOULD

+1. There is ample evidence in the IETF that, when you don't do that, 
people will guess wrong about a year after the spec comes out.

--Paul Hoffman, Director

---

From: Graham <[email-masked]>
Date: Mon, 4 Apr 2005 15:25:44 +0100

> our assigning requirements levels.

Right:
1. Feed level ids.
By all reasonable web conventions, requesting a feed from a particular 
URI can be expected to only ever return one particular feed resource. 
Whereas, the request will also return an essentially random combination 
of entry resources. Entry ids are a MUST because of the latter, which 
doesn't apply to feeds.

A separate feature of entry or feed ids is comparison and 
duplicate-removal across URIs. Since many users/implementers may choose 
not to do this due to concerns over security and potentially 
unexpected-behaviour, it can be described as "truly optional" 
functionality, which makes it MAY.

2. Link rel=self
Subscribing to feeds is a fundamental feature, and since the whole 
purpose of "self" is to make it simple and reliable, this element is 
not optional, and it's reasonable to say it must be present. But I can 
think of a few edge cases where the service generating the XML may not 
know its eventual URI, and of course there may be circumstances where 
there isn't one. This is the only reason I can think of to omit it. 
Since "SHOULD" allows implementers to wimp out for any reason they 
choose, I think the appropriate wording is "MUST where one exists and 
is known".

3. Link rel=alternate
Sorry Sam, but this is "truly optional" as per MAY. Being able to click 
back to the home page is nice, but how is it an "absolute requirement"?

Graham

---

From: Graham <[email-masked]>
Date: Mon, 4 Apr 2005 15:54:00 +0100

On 4 Apr 2005, at 4:59 am, Robert Sayre wrote:

> come from?

Well, things don't just appear, do they:
If it arrived over HTTP: You should know, you requested it. From a 
server with whois information and port 25 and a front page and a 
million other things.
If it arrived over email: The from address.
If you found it on a local disk: Somebody put it there.

There's no guarantee that alternate points anywhere useful. If you want 
to write up a proposal suggesting a required, verified troubleshooting 
contact, please do, but don't use it to justify something unrelated.

Graham

---

From: Sam Ruby <[email-masked]>
Date: Mon, 04 Apr 2005 11:01:15 -0400

http://www.intertwingly.net/wiki/pie/PaceFeedIdOrAlternate

Background: there seems to be some feeling that *something* should be 
required.  Opinions vary from id should be a MUST to id is at best a MAY.

While there are use cases for feeds without alternate html 
representations, I've been concerned that they are such outliers that 
the would be mostly ignored by the predominant feed producers; with the 
inevitable result that such feeds would be poorly handled and would 
therefore reflect poorly on both the authors of such feeds and the feed 
format itself.  As this issue keeps coming up, this concern is lessening 
for me.

Notes: this pace was written in such a way to minimize the amount of 
change to the existing document.  It does not express a preference 
between the two elements.  Upgrading one or both elements to a SHOULD 
would require a separate Pace.  Upgrading the Self link to a SHOULD or 
MUST would require a separate Pace.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Mon, 4 Apr 2005 09:18:30 -0600

On Sunday, April 3, 2005, at 05:16  PM, Robert Sayre wrote:
> Tim Bray wrote:
>> Well, yeah, but when they do the half-hour's coding it's going to 
>> cost them to start supporting Real IETF Atom 1.00 (tm), they can do 
>> an extra 3 minutes and if there's no <link>, they don't make the 
>> subscription clickable.
>
> think they didn't fix it?

Perhaps a combination of:

* Because the RSS spec says its required
* Because it doesn't cause any serious problems like a computer or 
application crash, just an unexpected page to be shown when the link is 
clicked
* Because nobody who we assume pointed it out to them complained loudly 
since it didn't cause any serious problems
* Because they had more important things to do

Both the amount of work required to enable an app to handle linkless 
feeds and the negative impact of not having the link are trivial as far 
as I can see, except for Bill's point about wanting an identifier for 
the feed.

On Monday, April 4, 2005, at 06:25  AM, Bill de hÓra wrote:
> Anyway I've made my position clear at this point. Please make id or 
> self mandatory.

I'd be opposed to link[@rel="self"] or link[@rel="alternate"] being 
mandatory since uses cases have been put forth for not having a 
reasonable value for either, but not opposed to either or both being 
SHOULDs. I also wouldn't be opposed to a feed being required to have 
either a link[@rel="self"] or an id.

---

From: Brett Lindsley <[email-masked]>
Date: Mon, 04 Apr 2005 10:39:40 -0500

How about a link[@rel="homepage"] for feeds that actually have a
home page to point to. By the same reasoning, link[@rel="alternate"]
would exist if the feed actually had an alternate representation. Both
of these would be MAY.  This would be consistent with how the spec
currently treats the prev, next, etc. with the verbage "atom:feed elements
MAY contain additional atom:link elements beyond those described
above" Sec 4.1.1.

If all of these links are MAY, then the only effect of the client is the
ability to have more features if they are included. I can't think of an
example where the client would fail to function if one if them would
be excluded (no reason for a MUST).

Antone Roundy wrote:

> application crash, just an unexpected page to be shown when the link 
> is clicked
> * Because nobody who we assume pointed it out to them complained 
> loudly since it didn't cause any serious problems
> feeds and the negative impact of not having the link are trivial as 
> far as I can see, except for Bill's point about wanting an identifier 
> for the feed.
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 04 Apr 2005 11:43:38 -0400

Paul Hoffman wrote:
> Good, we're making progress.

Not really. We get to design our protocol, and we know the type of 
software that will be consuming a large part of the traffic. All of that 
software expects a feed-level link. There are use cases where that's 
awkward, but I can't believe people want to put these out on the open 
Internet without an alternate.

> You're aiming at the "to limit behavior 
> I'm fine with making one of them a MUST for that reason. atom:id seems 
> like the one that would most help tracking down problems, yes?

Nope. That could very well be a non-heirarchical scheme like urn:uuid. 
This is not necessarily about full-on buggy software. Making atom:id 
mandatory does seem low-cost; if the producer can't do it once, they'll 
never do it for the entries. There are lots of situations where the 
software is behaving correctly but the content is confusing to the 
end-user. Feed-level links help to resolve that confusion. Without the 
link, non-bugs become a problem.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 4 Apr 2005 10:22:13 -0600

On Monday, April 4, 2005, at 09:43  AM, Robert Sayre wrote:
> I can't believe people want to put these out on the open Internet 
> without an alternate.
Feeds are the only kind of resource on the internet that I'm aware of 
that routinely have alternate representations.  Thinking about it from 
that direction, why one WOULD want a feed to have an alternate 
representation becomes a more important question than would one 
WOULDN'T.  Here are the reasons I can think of:

* Feeds emerged in the context of an internet where virtually everybody 
had a web browser, but virtually no one had a feed reader.  Having only 
a feed severely limited one's reach.
* Feeds emerged in the context of an internet where publishers were 
already publishing HTML representations of the data they started 
putting into feeds.
* Feeds began as a method of announcing the existence of new data on 
web pages, not as a method of delivering full content.
* There are established and accepted methods of building revenue 
streams from web pages--ie, we know where to put ads in web pages.  
Until people figure out how to monetize their feeds, many will want to 
use them to drive people to their web pages.

It seems to me that the reasons for having alternate links in feeds are 
almost entirely based on the context in which feeds originally emerged. 
  These conditions still apply to many feeds, but not all.  I don't see 
any reason to try to force feeds to continue to be the unusual internet 
resource that always has an alternate representation.

Antone

---

From: Antone Roundy <[email-masked]>
Date: Mon, 4 Apr 2005 10:37:53 -0600

I think requiring either atom:id or atom:link[@rel="self"] would make 
more sense.   It's entirely conceivable that multiple feeds might exist 
that claim to be alternates of the same resource--for example, a full 
content feed vs. a summary feed; a scraped feed vs. an official feed 
(...in which case, the scraped feed might be a copyright violation, but 
that's a separate matter); a feed of the tech news entries in a blog 
vs. a feed of the personal entries in the same blog; etc.  Requiring id 
or self would ensure that consumers had a somewhat reliable value to 
use as an identifier for each feed.  Alternate, on the other hand, may 
not be useful as an identifier, so it really doesn't fill the same 
space as id, and thus it doesn't make sense to me to use those two as 
alternatives for filling a feed requirement.

Antone

On Monday, April 4, 2005, at 09:01  AM, Sam Ruby wrote:
> the would be mostly ignored by the predominant feed producers; with 
> the inevitable result that such feeds would be poorly handled and 
> would therefore reflect poorly on both the authors of such feeds and 
> the feed format itself.  As this issue keeps coming up, this concern 
> is lessening for me.
>

---

From: Henry Story <[email-masked]>
Date: Mon, 4 Apr 2005 18:41:50 +0200

This is very convincing to me.

Henry

On 4 Apr 2005, at 18:22, Antone Roundy wrote:
> * Feeds emerged in the context of an internet where virtually 
> everybody had a web browser, but virtually no one had a feed reader.  
> Having only a feed severely limited one's reach.
> It seems to me that the reasons for having alternate links in feeds 
> are almost entirely based on the context in which feeds originally 
> emerged.  These conditions still apply to many feeds, but not all.  I 
> don't see any reason to try to force feeds to continue to be the 
> unusual internet resource that always has an alternate representation.
>
> Antone
>

---

From: Robert Sayre <[email-masked]>
Date: Mon, 04 Apr 2005 13:02:36 -0400

> almost entirely based on the context in which feeds originally emerged. 

This isn't a good time for conjecture. I don't think any of the 
arguments in favor have considered the support burden such feeds will 
create. OTOH, the absolute worst thing to do right now would be to sit 
around and argue this for a week. I'm very opposed to getting inventive 
and making this a MAY. I'm not changing my mind, but the group will 
probably just define it over my objection. Happens all the time :)

Robert Sayre

---

From: James Aylett <[email-masked]>
Date: Mon, 4 Apr 2005 18:00:21 +0100

On Mon, Apr 04, 2005 at 11:43:38AM -0400, Robert Sayre wrote:

> We get to design our protocol, and we know the type of software that
> will be consuming a large part of the traffic.  All of that software
> expects a feed-level link. There are use cases where that's awkward,
> but I can't believe people want to put these out on the open

Depends what you mean by "the open Internet": what about
password-protected web products? Also, there's an implication here
that we don't care about making life hard for denizens of "the closed
Internet", giving them the choice between abusing Atom and choosing
something entirely different.

I have yet to hear a reason to make alternate a MUST that is
compelling. That existing software (which by definition can't be an
IETF Atom client) expects a link to ... some kind of HTML ... doesn't
cut it for me, not least because the current atom-syntax spec doesn't
require a link to some kind of HTML at all anyway.

At the end of the day, I don't think it's possible to make the
question "is X an alternate version of Y" anything other than a
subjective call. As such, I don't see the value of making it a MUST -
forcing to export their opinions isn't /always/ the purpose of a blog
format :-)

James

---

From: Graham <[email-masked]>
Date: Mon, 4 Apr 2005 19:17:05 +0100

On 4 Apr 2005, at 6:02 pm, Robert Sayre wrote:

> create.

Basically none. I have no clue why you're raising this objection given 
all the other functionality we're adding or replacing. Links now being 
optional is right at the bottom of the list of changes people will have 
to make.

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 04 Apr 2005 20:47:13 +0100

> time, and mutability is not a good attribute of an identifier.

Yes, your other post convinced me that atom:link[@rel='self'] needs to 
be optional.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Thu, 7 Apr 2005 15:55:06 +0200

Here is a nice small surgical change.

I am not sure if I have convinced Thomas Broyer with the diagrams I put 
online,
but I am still very happy with the following replacement, after having 
carefully
looked at the criticisms.

Proposal A
----------

replace

[[

with:

[[