the widely divergent personal
and partial views that are obvious in many our conversations today...
bob wyman
reading this feed. Read the Atom 1.0
feed instead...
bob wyman
of
30 minutes which is implied by a polling frequency of 1 hour.
You've written on your blog that you want to see more 304
responses. Well, I would suggest that what you *really* should want is more
226 responses -- 226 is the success code for an RFC3229+feed GET
operation.
bob
is not a requirement of the
language, but it is a clear derivative of it.
Basically,
you dont have to update atom:updated unless you think it makes sense OR
you are publishing to a feed that already has an entry with the same atom:id as
the atom:id of the entry you are currently publishing.
bob wyman
For yet another reason why aggregators deliver up duplicate entries,
See: http://bobwyman.pubsub.com/main/2005/05/rss_ads_done_th.html
Hopefully, Atom V1.0 will make it easier for us to isolate our users from
the impact of poorly designed advertising programs...
bob wyman
, then comparison code would know what bits to ignore -- whether or
not they were ad related.
span dynamic
The time of day is: 5:25pm EST.
/span
bob wyman
going on.
bob wyman
from which a feed is actually read.
I would much prefer if the *real* entry id was built from the concatenation
of the URI of the source feed, as identified in a link element (with
rel=self) and the atom:id of the entry.
bob wyman
atom id. The point of the require source language is not to remove the
requirement for uniqueness but rather to provide a more useful way of doing
cross-feed determination of uniqueness.
bob wyman
be accepted and the specification revised.
bob wyman
in the claimed source. We may publish the suspect entry with a new
id or we may simply discard the suspect entry. What do you suggest?
Any ideas you may have for handling these cases would be
appreciated.
bob wyman
that are problematic.
bob wyman
before!
bob wyman
'/
modified2005-04-25T02:20:56-04:00/modified
author
namePubSub Feed Generator/name
/author
ps:update-count369/ps:update-count
ps:subidd9/e6/4eb045b8ddaf1923b44b049753/ps:subid
title![CDATA[PubSub: Topix]]/title
bob wyman
to the specification...
bob wyman
[1] http://www.pubsub.com/earthquakes.php
[2] http://www.pubsub.com/downloads.php
the syndication systems does not apply once the
content is removed from the system. (Note: This may be a *very* important
point... but is one for the lawyers, not us mere mortals.)
bob wyman
atom:feed elements have identical atom:id values yet only one of them
has an atom:source element with a rel value of self, that element which
contains the atom:source element with rel value of self SHOULD be
preferred over the other.
bob wyman
at the language can
figure out how to write this into the spec.
Note: At PubSub, we expect to ensure that every entry we publish
once we move to Atom V1.0 will contain an atom:source with a self link.
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto
to be inserted into old Atom feeds to allow the
transition to the new atom as well as define extensions to the various
flavors of RSS. If we can implement this minor extension, we may see many
fewer duplicate feeds being consumed and thus fewer duplicate entries.
Comments?
bob
but now decided to switch to an Atom feed, how would the
aggregators discover that this was your intention without causing a break in
their ability to process your posts?
bob wyman
-Original Message-
From: Robert Sayre [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 07, 2005 1:44
content that
we have available to us.
I'm not sure they'd pay attention to feed links either
I *guarantee* you that if we had an accepted way to address this in
feeds, PubSub *would* pay careful attention to it.
bob wyman
to the
slash:comments element? If so, are there other elements that should be
ignored?
Now, Spaces only publishes RSS feeds... However, if similar atom
extensions were to be defined, the problem would appear with Atom feeds as
well.
bob wyman
[1]
http://spaces.msn.com/members/carnage4life
note. i.e.
Entries will be considered duplicates if
Shrook uses an adaptive subset that means that if one element is
unreliable it uses the others.
Can you describe your algorithm? What do you consider unreliable
to mean?
bob wyman
...). (Yes, I know it
probably should be application/xml and would ideally be specific as to
type since we know it is RSS or Atom, etc. But, that's not the point of this
discussion.).
bob wyman
include full category data in the entries
they publish rather than publishing entries into specialized feeds as the
way to indicate category.
bob wyman
(and there is a great deal of
it) is the problem of some other element to handle.
bob wyman
Eric Scheid wrote:
On 8/4/05 6:17 AM, Bob Wyman [EMAIL PROTECTED] wrote:
The proposal I made relies on a feed making statements only about
itself. In my proposal, a feed can only say: I contain copies of
these other feeds. I am a secondary feed.
How does this prevent DOS attacks? If I could
start
expiring.
So, in summary, let's not go down the DRM path. It is a snake pit
from which no good will come. Also, please see my post about Creative
Commons at:
http://bobwyman.pubsub.com/main/2005/03/lazyweb_query_a.html
bob wyman
ccess to or use of data. Because
this point is a bit subtle, were likely to have all sorts of people
thinking that providing support for Creative Commons does, in fact, give them
the ability to restrict the use of their data
bob
wyman
that it
is no longer required.
bob wyman
The following message was on the RSS-Media
group at:
http://groups.yahoo.com/group/rss-media/
It seems reasonable to expect that users
will expect that Atom and RSS-Media will, in fact, be used in concert in the
future.
From: ecomputerd
[mailto:[EMAIL PROTECTED]
Sent: Tuesday,
, the best an intermediary can do
is keep track of date_entry_was_found. However, this can cause problems
since entries can exist in multiple feeds. Thus, the order in which the
feeds are read can cause old entries to over-write newer ones.
bob wyman
of the maintain atom:id rule, etc.
Forbidding repeated ids causes damage. History shows, however, that
allowing repeated ids is benign.
bob wyman
feeds, etc. will come to the same
conclusion in time.
Have a good day. I'm sure you'll all be pleased to know that I won't
be bothering you about this in the next few days. Do what you will...
bob wyman
for an entry was the concatenation of atom:id + (atom:revision OR
atom:modified), then we would no longer require the archive document type at
all...
But, I won't go there...
bob wyman
.
Similarly, the prohibition against multiple instances of an atom:id
means that we can't implement a show me all versions feature using Atom as
the packaging format for the results. (No, we're not planning to do this.
But, it would be good to be able to do it.)
bob wyman
[1] http
compromises the utility of
aggregation and search mechanisms. This should not be tolerated.
bob wyman
should be specified *within*
entries, not implied or derived from the context within which those entries
are found.
It's about the Entries, Stupid!
bob wyman
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to try to
rush through something this major at the last moment before a pending Last
Call.
bob wyman
want to see is the
most recent state of the entry. To provide this, we need a way to link
together the various versions or states of the entry -- that is done with
atom:id. Priority of the versions is determined using atom:modified...
bob wyman
Clearly, I meant atom:updated not atom:modified... My apologies for the
slip.
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bray
Sent: Friday, February 04, 2005 7:11 PM
To: [EMAIL PROTECTED]
Cc: 'Mark Nottingham'; 'Paul
that Atom use will provide virtually no advantage to anyone who is
building aggregated feeds.
bob wyman
service that I recently
mentioned on this list. We will be publishing both raw Earthquake messages/feeds
as well as CAP messages/feed in the future. These two formats are targeted at
different audiences.
Your comments and/or suggestions would be appreciated.
bob
wyman
like Lisp.
As an ex-Visual Basic Product Manager, I think this would be a good
idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to
reader: Visual Basic .NET is .NOT Visual Basic...
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto
should NOT be significant. This
is, I think, a very, very important point to make.
bob wyman
that which we can not do...
bob wyman
I thought atom:host was made redundant by the combination of HeadInEntry and
FeedLink...
bob wyman
. That's the way the real world works.
bob wyman
to a standard Entry Retracted page that is shared by all
retracted entries? (i.e. http://example.com/no_such_page.html )
bob wyman
repetition of feed meta data in head/ elements is
probably acceptable.
I may have forgotten some of the arguments, but this should provide
a good refresher and/or catch-up on the basic issues...
bob wyman
assistance. My
hope is that well be able to use Atom to make a real contribution to
making the world just a bit safer
bob
wyman
then you could add any content you wanted
without interfering with the signature mechanism. Note: A signature on an
Atom feed should *not* contain the XPath above.
bob wyman
[1] http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-XPath
[2] http://www.imc.org/atom-syntax/mail-archive/msg09604
forward to your comments and assistance in getting
this system working hopefully, long before the next disaster in which
it might be useful.
bob wyman
Note: The message below was published long after the original event.
The reason for the delay is that this message adds to information previously
...
bob wyman
[1] http://www.w3.org/PICS/
in
existence requires elements of atom:head when handling entries. I can
imagine very few applications (other than closed ones) that could make use
of atom:entries that do not contain atom:head elements and are not
themselves enclosed in atom:feeds.
bob wyman
in the future? If we don't finish Atom
and get the extensibility questions resolved, it is certain that they will
stick to RSS V1.0.
bob wyman
[1] http://www.dlib.org/dlib/december04/hammond/12hammond.html
=classificationpolitics/prop
prop name=priorityvery_high/prop
Let's focus on the mechanism for communicating properties rather
then the specific properties that are to be communicated.
bob wyman
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf
101 - 157 of 157 matches
Mail list logo
