One reason for title only feeds is to address bandwidth limited devices.
The
server I set up provides the same feed in two different formats - one title
only and the other with title/summary/etc. The end client can decide which
feed it wants to work with based on its capabilities; however, both
On Wed, 27 Apr 2005 06:35:21 -0400, Sam Ruby [EMAIL PROTECTED]
said:
While I agree that the implications of a decision to omit a summary need to
be understood and carefully weighed by the feed author, I don't believe that
mandating the summary element actually achieves this
So.. can we
* Sam Ruby [EMAIL PROTECTED] [2005-04-27 12:45]:
So.. can we agree on SHOULD?
+1. My previous tentative +1 for MAY is hereby withdrawn.
Regards,
--
Aristotle
Atomes,
One of the goal of the Atom initiative is to obtain a simple but powerful
way to handle metadata. The International Press Telecommunications Council
(IPTC) studies the same kind of problems in the domain of professional
news-worthy information, and we feel that the Atom WG could be
I used title=titles and title=full to indicate the varients in the
feed discovery
while maintaining compliance with the current spec. The user must select
which
feed to use.
One assumption I am making is that the updated time for both the title only
and the full entry are the same. If I have a
On 28/4/05 12:10 AM, Antone Roundy [EMAIL PROTECTED] wrote:
feed
link rel=variants ... /!--this is a link to a file listing
variants--
link rel=complete ... /!--this is a link to a variant which
contains all of the elements found in any variant--it's conceivable
that no such variant may
On Wednesday, April 27, 2005, at 08:53 AM, Eric Scheid wrote:
why not
feed
link rel=alternate type=application/xml+atom title=minimal/
link rel=alternate type=application/xml+atom
title=authoritative/
link rel=alternate type=application/xml+atom
title=summmaries/
...
/feed
and
I know that nobody seems to like
this issue However, I have explained on numerous occasions that the
existing prohibition against duplicate ids in a feed simply cannot be supported
by PubSub or any other feed aggregator. The problem is, once again, that
prohibiting duplicate ids provides
Bob Wyman wrote:
I know that nobody seems to like this issue However, I have explained
on numerous occasions that the existing prohibition against duplicate
ids in a feed simply cannot be supported by PubSub or any other feed
aggregator. The problem is, once again, that prohibiting duplicate
Bob Wyman wrote:
I know that nobody seems to like this issue However, I have explained
on numerous occasions that the existing prohibition against duplicate
ids in a feed simply cannot be supported by PubSub or any other feed
aggregator. The problem is, once again, that prohibiting duplicate
At 11:48 AM -0400 4/27/05, Bob Wyman wrote:
I know that nobody seems to like this issue However, I have
explained on numerous occasions that the existing prohibition
against duplicate ids in a feed simply cannot be supported by PubSub
or any other feed aggregator. The problem is, once again,
Bill de hÓra wrote:
What will prevent people overwriting the atom:[EMAIL PROTECTED]'self'] links
as well as the id?
Now you see why Graham Park's proposal is a compromise. It
improves things but doesn't provide a definitive solution to all cases. It
means a great deal more processing
On 28/4/05 2:09 AM, Henry Story [EMAIL PROTECTED] wrote:
B- the simple solution which simply allows entries with duplicate
ids
+1
On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote:
Proposal for thinking about: to simplify the spec, atom:summary
should either be a MUST in all cases or a MAY in all cases. If it is
just semantic like atom:category, it should be a MAY. If it is
inherently valuable like atom:title, it should be a
On 27 Apr 2005, at 6:00 pm, Bob Wyman wrote:
Paul Hoffman wrote:
Question (not a disagreement): Why wouldn't the later entry be
dropped instead of the first one being flushed?
The order of entries is not significant for the subject attack. The
reason is that it is possible for an attacker to
Henry Story wrote:
I think we should vote on the two solutions:
A- the compromise solution you propose
B- the simple solution which simply allows entries with duplicate ids
C- No change
My preference is clearly B then A, and certainly not C.
Same for me.
As far as I am concerned there
On 4/27/05, Bob Wyman [EMAIL PROTECTED] wrote:
In the absence of evidence that the proposed change will result in
damage or interoperability problems, I think the spec must change. A
security note is not sufficient.
OK, we have two errors to balance here. One of them is the text we
Walter Underwood wrote:
I'm not being entirely silly here. We could distinguish between
I am not providing a summary (no element) and the summary is void
(empty summary).
+1
This means I agree with Rob that these [1] three entries mean different
things.
[1]
Well said, Paul; this articulates the reasons for a profiling mechanism
much more effectively than I ever did.
Cheers,
On Apr 27, 2005, at 9:28 AM, Paul Hoffman wrote:
A few brief notes for the WG to chew on.
- Literal interpretation of 2119 for a document format such as Atom
would make nearly
At 6:47 PM +0100 4/27/05, Graham wrote:
On 27 Apr 2005, at 5:28 pm, Paul Hoffman wrote:
Proposal for thinking about: to simplify the spec, atom:summary
should either be a MUST in all cases or a MAY in all cases. If it
is just semantic like atom:category, it should be a MAY. If it is
inherently
Thomas Broyer wrote:
Antone Roundy wrote:
This raises a few questions:
1) How does one indicate the existence of variants?
[EMAIL PROTECTED]alternate or using a custom (read: extension)
relations or using extension elements. See also my comments
below on 3).
I'll just stop lurking for a minute
Antone Roundy wrote:
If PubSub is subscribed to the feed pointed to by
atom:[EMAIL PROTECTED]'self'], then can't you simply drop any entries
claiming to be from that feed but found at a different URI? You'll be
getting those entries from the source if they're legitimate, so is
there any
On Wednesday, April 27, 2005, at 05:11 PM, Graham wrote:
On 27 Apr 2005, at 10:31 pm, Robert Sayre wrote:
My opinion is that ~10 WG members are currently clearly stating their
belief that summary/content are optional.
You should make clear that most of those people supported a misleading
Pace
23 matches
Mail list logo
