Re: PaceNoAlternateForFeed
On Tue, May 10, 2005 at 12:10:33AM +0100, Graham wrote: > > 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)? 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 where it's reasonable for there to be no link. The presence of a "no 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 PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: PaceNoAlternateForFeed
On 5/9/05, Graham <[EMAIL PROTECTED]> wrote: > > On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: > > > 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. > > So you wouldn't support a proposal that removed a required element > 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. > 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)? 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
Re: PaceNoAlternateForFeed
Graham wrote: On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: 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. 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)? 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). 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? Answer Tim's question: "What observable difference in the behavior of 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
Re: PaceNoAlternateForFeed
On 9 May 2005, at 6:48 pm, Bill de hÓra wrote: 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. 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)? 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? Answer Tim's question: "What observable difference in the behavior of software would be affected by this difference?" Graham
Re: PaceNoAlternateForFeed
Tim Bray wrote: On May 9, 2005, at 8:13 AM, Bill de hÓra wrote: 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. 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
Re: PaceNoAlternateForFeed
On May 9, 2005, at 8:13 AM, Bill de hÓra wrote: 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. 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
Re: PaceNoAlternateForFeed
Julian Reschke wrote: Bill de hÓra wrote: ... 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. ... How is it "less ambiguous" if the spec states that the absence of the link means that there is no alternate information? It doesn't state that. But that would be logically the same to me. cheers Bill
Re: PaceNoAlternateForFeed
Bill de hÓra wrote: ... 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. ... 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
Re: PaceNoAlternateForFeed
Stefan Eissing wrote: 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? 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
Re: PaceNoAlternateForFeed
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
Re: PaceNoAlternateForFeed
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 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. cheers Bill
Re: PaceNoAlternateForFeed
Bill de hÓra wrote:
...
{{{
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".
}}}
...
> ...
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
Re: PaceNoAlternateForFeed
Antone Roundy wrote: 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:[EMAIL PROTECTED]'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:[EMAIL PROTECTED]'alternate'] exists is irrelevant to that requirement. Do you want to edit the pace text to make it right? cheers Bill
Re: PaceNoAlternateForFeed
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:[EMAIL PROTECTED]'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:[EMAIL PROTECTED]'alternate'] exists is irrelevant to that requirement.
PaceNoAlternateForFeed
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:[EMAIL PROTECTED]'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
{{{
http://purl.org/atom/ns#draft-ietf-atompub-format-08";>
dive into mark
A <em>lot</em> of effort
went into making this effortless
2005-04-02T12:29:29Z
tag:example.org,2003:3
Copyright (c) 2003, Mark Pilgrim
}}}
* 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
