Subject: PaceNoAlternateForFeed

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 15:11:56 +0100

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

== Abstract ==

Allow publishers to indicate when they have no alternate link for a feed.

Author: BillDehora

== Status ==

Open

Incept: 2005-05-09

Written against: 
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt

== Rationale ==

Not all publishers have a suitable alternate link for a feed. Example 
cases include subversion repositories [1], and mail archives [2].

== Proposal ==

In section 4.1.1 change the tenth bullet point

{{{
  o atom:feed elements MUST contain at least one atom:link element
       with a relation of "alternate".
}}}

to

{{{
  o atom:feed elements MUST contain either and cannot contain both
      - one or more atom:link elements with a relation of "alternate".
      - one and only one atom:link element with a relation of 
"no-alternate".
}}}

== Impacts ==

  * PaceFeedIdOrAlternate: none, that pace is withdrawn.

  * PaceFeedIdOrSelf: that pace suggests pointing to self in the absence 
of an atom:link[@rel='alternate'] or an atom:id. This pace suggests 
allowing the publisher to state there is no alternate.

== Notes ==

Fragment example derived from 1.1 example 2 in draft-08

{{{
<feed xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-08">
      <title type="text">dive into mark</title>
      <subtitle type="html">
        A &lt;em&gt;lot&lt;/em&gt; of effort
        went into making this effortless
      </subtitle>
      <updated>2005-04-02T12:29:29Z</updated>
      <id>tag:example.org,2003:3</id>
      <link rel="no-alternate" />
      <copyright>Copyright (c) 2003, Mark Pilgrim</copyright>
}}}

  * The author is not attached to the token 'no-alternate'. Any other 
token is fine once we agree that it states the publisher is saying there 
is no alternate link for this feed.

  * The author is fine with a SHOULD provide rather than MUST provide.

  * Whether atom:feed/atom:id MUST be present in the absence of an 
alternate be present can be argued about separately from whether there 
is no alternate. see PaceFeedIdOrSelf.

cheers
Bill

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

---

From: Antone Roundy <[email-masked]>
Date: Mon, 9 May 2005 08:36:46 -0600

On Monday, May 9, 2005, at 08:11  AM, Bill de hÓra wrote:
>  * PaceFeedIdOrSelf: that pace suggests pointing to self in the 
> absence of an atom:link[@rel='alternate'] or an atom:id. This pace 
> suggests allowing the publisher to state there is no alternate.
>
Not quite right--that pace requires pointing to self in the absence of 
an atom:id.  Whether or not atom:link[@rel='alternate'] exists is 
irrelevant to that requirement.

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 15:47:51 +0100

> irrelevant to that requirement.

Do you want to edit the pace text to make it right?

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 May 2005 16:56:26 +0200

Bill de hÓra wrote:
> ...
> ...
 > ...

Is this meant to be a serious proposal? Why can't ve just leave a 
protocol element out if we don't have information for it???

Best regards,

Julian

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 16:13:01 +0100

Julian Reschke wrote:

> Is this meant to be a serious proposal? 

It's a serious proposal. Why would you think otherwise?

> Why can't ve just leave a 

Because it allows someone to assert there is no alternate link for their 
feed. That's different from leaving an alternate link out.

cheers
Bill

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 9 May 2005 17:27:30 +0200

Am 09.05.2005 um 17:13 schrieb Bill de hÓra:
>> Why can't ve just leave a protocol element out if we don't have 
>> information for it???
>
> Because it allows someone to assert there is no alternate link for 
> their feed. That's different from leaving an alternate link out.

Does not compute. How is that different for a feed reader?

If you say that there is no alternate link for your feed and I make 
your very feed available through "my" server, does your feed have an 
alternate link or not?

//Stefan

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 16:50:07 +0100

> Does not compute. How is that different for a feed reader?

Why does it need to be different for a feed reader?

> If you say that there is no alternate link for your feed and I make your 
> very feed available through "my" server, does your feed have an 
> alternate link or not?

We could just as easily argue about all the possible such URLs that 
might be the case but aren't listed as alternates. Are they alternate 
links? What about an alternate link  I added for the sake of spec, 
because I have no alternate. Is that an alternate link? Such 
counterfactuals are fun, but have no bearing here.

Currently you MUST provide an alternate feed link. People are saying 
they don't  always have one to provide, which encourages garbage out. 
That satisfying a spec constraint for its own sake. This addition allows 
someone to say there is no alternate for this link. It's less ambiguous 
than not providing an alternate and more useful than providing junk 
links. Not present is not the same as not the case.

cheers
Bill

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 May 2005 18:01:38 +0200

> links. Not present is not the same as not the case.

How is it "less ambiguous" if the spec states that the absence of the 
link means that there is no alternate information?

Best regards, Julian

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 17:34:58 +0100

Julian Reschke wrote:
>> That satisfying a spec constraint for its own sake. This addition 
>> allows someone to say there is no alternate for this link. It's less 
>> ambiguous than not providing an alternate and more useful than 
>> providing junk links. Not present is not the same as not the case.
>> ...
> 
> 

It doesn't state that. But that would be logically the same to me.

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Mon, 09 May 2005 10:26:10 -0700

> their feed. That's different from leaving an alternate link out.

What observable difference in the behavior of software would be 
affected by this difference?  It's not obvious to me that there's a 
meaningful difference.   -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 09 May 2005 18:48:52 +0100

Tim Bray wrote:
> What observable difference in the behavior of software would be affected 
> by this difference?  It's not obvious to me that there's a meaningful 
> difference.   -Tim

The difference is in what can be concluded from the data, ie it's a 
3-valued logic problem.  Does the absence mean there's no alternate? 
Does it mean don't unknown? Do we need to care?

I think this exercise is *critical* for any piece of markup that is 
going to move from mandatory to optional. Either way, we should pin down 
spec language around the optionality of alternate feed links, or 
consciously decide we're not going to pin it down.

cheers
Bill

---

From: Graham <[email-masked]>
Date: Tue, 10 May 2005 00:10:33 +0100

On 9 May 2005, at 6:48 pm, Bill de hÓra wrote:

> going to move from mandatory to optional. Either way, we should pin  
> down spec language around the optionality of alternate feed links,  
> or consciously decide we're not going to pin it down.

So you wouldn't support a proposal that removed a required element  
without explaining what it's absence meant (eg PaceAtomSummary),  
because you'd prefer one that leaves it much less ambiguous (eg  
PaceTextShouldBeProvided, which strongly encourages publishers to  
only omit atom:summary when none exists)?

> 3-valued logic problem.  Does the absence mean there's no  
> alternate? Does it mean don't unknown? Do we need to care?

Answer Tim's question: "What observable difference in the behavior of  
software would be affected by this difference?"

Graham

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 10 May 2005 00:46:59 +0100

Graham wrote:
>> down spec language around the optionality of alternate feed links,  or 
> PaceTextShouldBeProvided, which strongly encourages publishers to  only 
> omit atom:summary when none exists)?

I'm not surprised at this line of thought since there is also another 
dicussion going on around optional summaries. You're jumping the gun 
though and/or possibly trying to pin me into some kind of non-existent 
corner - fair enough. What I would like is that we at least discuss the 
consequences of making non-optional things optional on the data beynd 
some people can't supply meaningful alternates - I happen to be one of 
those people btw, if I haven't said it already. And some consistency of 
debate around loosening constraints is good I think. Finally, there is 
an important distinction between the two cases (optional alternates and 
optional summaries).

> software would be affected by this difference?"

I can have nullable columns in my database depending on what we decide 
to do here. That affects the behaviour of my SQL queries and depending.

I can can constrain the search for alternates in a nypertext graph if I 
know the author is saying there is no alternate. That affects (massively 
in some cases) the behaviour of an RDF query backend among other things. 
similar arguments can be made for search systems that are working off 
raw  indexes.

I can send the message "there is no alternate for this feed" or "no 
alternate was provided for this feed" or "no alternate was found for 
this feed" depending on what we decide to do here.

Is that enough? Do you see that the point of this pace is to shine some 
light on what we're doing here? Btw, I'm 0 on PaceNoAlternateForFeed - 
like I said, I have feeds that have no real alternates.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Mon, 9 May 2005 19:48:34 -0400

> without explaining what it's absence meant (eg PaceAtomSummary),

No, he consciously decided it wasn't worth pinning down, because
there's no interop to be gained. Party foul for bringing this issue up
in yet another thread, BTW.

> only omit atom:summary when none exists)?

I've read PaceTextShouldBeProvided, and I don't understand its
rationale, but I can tell you there is absolutely nothing in the
proposal section "which strongly encourages publishers to only omit
atom:summary when none exists". All it says is that things might break
if you don't include a summary or include empty text constructs.

Robert Sayre

---

From: David Nesting <[email-masked]>
Date: Mon, 9 May 2005 20:31:42 -0500

> only omit atom:summary when none exists)?

There's a difference between atom:summary and atom:link.  

The first is a product of the RESOURCE the entry is pointing to.  The lack
of a summary in the entry does not necessarily imply that the RESOURCE has
no summary, only that no summary exists in this entry.  The presence of
an empty summary is a statement that the summary "exists", but is empty.

The second is a product of the FEED: here's a link that has something
to do with the feed itself.  The feed is the sole authority on things
(meta data) related to the feed.  The absence of an alternate link and
the presence of an "empty" link are BOTH statements that no alternate
link exists.  One can not reasonably infer that the lack of a link is
somehow the feed being uncommunicative about its own state.  There is
insufficient difference between the two to mean anything significant
to software/readers.

It seems most reasonable to me to simply allow the lack of a <link> where
it's reasonable for there to be no link.  The presence of a "no link" <link>
provides no additional information than the omission would.  This is not
the same as the summary, where the feed may not be the authority on the
resource it's pointing to.

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