On 6/5/05 1:07 PM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:
Hrm. This is an interesting point. I'm not too concerned about find
every feed, regardless of relevance because I think only search engines
will be interested in it, especially if all the other cases are marked.
finding
fantasai wrote:
The difference between link and a is that
- link applies to the document as a whole: it indicates a relationship
between this document and the href destination.
- a is a contextual link: it indicates a relationship between the
linking context and the href destination.
Nikolas 'Atrus' Coukouma wrote:
fantasai wrote:
Actually, I think start is the best fit. The main feed is often not a
table of contents to the entire weblog, but something partial. It is,
however, the starting point of the collection.
Actually, I disagree with start because of the first sentence
Eric Scheid wrote:
On 6/5/05 1:07 PM, Nikolas 'Atrus' Coukouma [EMAIL PROTECTED] wrote:
Hrm. This is an interesting point. I'm not too concerned about find
every feed, regardless of relevance because I think only search engines
will be interested in it, especially if all the other cases are
Robert Sayre wrote:
I'm much more sympathetic to the aggregate feed problem of multiple
IDs. People advocating this type of thing seem to think the default
action should be grouping, so they want to use the same ID. I think
that's a bad idea, and there are plenty of other ways to indicate the
Graham wrote:
On 6 May 2005, at 3:50 am, Sam Ruby wrote:
FYI: we have an instance proof of this requiring an existing tool to
do additional work:
http://www.imc.org/atom-syntax/mail-archive/msg13983.html
Tools will have to be updated to work with Atom? Scandalous.
+1 to the Pace
+1 as well.
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.
I like so agree. 226 support would be highly commendable for
everyone,
+1, in case it got lost in the earlier threads.
cheers
Bill
Graham wrote:
On 6 May 2005, at 3:50 am, Sam Ruby wrote:
FYI: we have an instance proof of this requiring an existing tool to
do additional work:
http://www.imc.org/atom-syntax/mail-archive/msg13983.html
Tools will have to be updated to work with Atom? Scandalous.
+1 to the Pace
This Pace is
Tim Bray wrote:
Speaking not as the chair but as an interested WG member, I read them
about eight times and I do not understand why they are in conflict.
Someone please explain, as simply as possible, what the problem is,
because I just don't get it. On the face of it, I am inclined to be +1
On 6 May 2005, at 1:26 pm, Sam Ruby wrote:
My concern is not that tools will need to be updated. My concern
is that tools won't know that they need to update. How will they
know that they need to update to handle a set of feeds that nobody
is currently providing?
How is this different to
Bill de hÓra wrote:
3. It's the kind of spec text we have rejected in the past as
impletation specific and/or best current practice guidance:
those that follow these suggestions will find that their feeds are
useful to a wider audience than they would be otherwise.
Um, that text is not part of
On 6 May 2005, at 2:10 pm, Dave Johnson wrote:
Yes, I think both of my arguments fail to hold and I no longer have
a real objection to duplicates. Allowing duplicates gives feed
produces to model events or other objects (versioned documents in a
wiki) as they wish. Like you, I wonder Does
On 5/5/05, Tim Bray [EMAIL PROTECTED] wrote:
The discussion in recent days has been lively but unstructured. If I
were forced to make a consensus call right now, I'm pretty sure I
wouldn't be able to pick out any one spec change that I could say
clearly has consensus.
The one suggestion I
Unique IDs allow clients to determine the state of the feed. If entry
ids are
not unique, then we still need some other way to determine the unique
state of the feed. If we allow duplicate IDs but *require* something else
to be different (e.g. update time), then we can still determine the
As the WG may have noticed, I have some serious problems with the
Pace. One small change would eliminate about 75% of them:
Replace the line:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MAY choose to display all of them or some subset of
them
with:
If
Graham wrote:
Does anyone remember why having the same id in a feed is a bad idea?
Beacuse instead of a fixed model where a feed is a stream of
entries each with their own id, it is now a stream of entries each
of which does not have its own id, but shares it with similar
entries. This is
What determines a version? If we have multiple entries with identical
information,
these are copies, not versions.
The real issue is feed state. Given there are identical IDs, can we
determine if
the entries are identical or different? The end client can then deal
with it any way
it wants
-1.
I agree with Robert; it conflicts with PaceOptionalSummary and I doubt
it would exist if PaceOptionalSummary had not make the cut. At best
level of specification belongs in the Fabled Implementor's Guide, not
the specification.
cheers
Bill
On May 6, 2005, at 7:09 AM, Graham wrote:
Replace the line:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MAY choose to display all of them or some subset of
them
with:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST
Mark Pilgrim wrote:
In case this got buried in the previous thread, last fall I wrote but
never publicized a minimal draft of an Atom Implementation Guide.
http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html
Due to my commitments elsewhere, I can not promise that I will ever
finish
Your co-chairs would like to ask a favor of the group. When doing our
last consensus call, it's going to be prohibitively difficult to go
back to the beginning of time. Thus, we'd like to start with Sam's
announcement of the issues list revision at
On 6/5/05 11:37 PM, Graham [EMAIL PROTECTED] wrote:
Beacuse instead of a fixed model where a feed is a stream of entries
each with their own id, it is now a stream of entries each of which
does not have its own id, but shares it with similar entries. This is
bullshit.
See the spec:
PaceAllowDuplicateIDs +1.
PaceDuplicateIDWithSource2 -1
PaceDuplicateIDWithSource -1
PaceExplainDuplicateIds +1
We have no clear reason to disallow the use-case, until we put our cards
on the table re what's being identified. So either PaceAllowDuplicateIDs
or PaceExplainDuplicateIds are
wrote:
Tim at a time into my inbox earlier than the above:
Given the volume of debate, it's obvious there may be more work to do
here. Paul and I have asked Phil Ringnalda to co-edit the autodiscovery
spec, and he's accepted.
Crossed wires?
Euh, the autodiscovery specification is not really
Anne van Kesteren wrote:
wrote:
Tim at a time into my inbox earlier than the above:
Given the volume of debate, it's obvious there may be more work to do
here. Paul and I have asked Phil Ringnalda to co-edit the
autodiscovery spec, and he's accepted.
Crossed wires?
Euh, the autodiscovery
On 7/5/05 12:39 AM, Bill de hÓra [EMAIL PROTECTED] wrote:
http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html
Due to my commitments elsewhere, I can not promise that I will ever
finish this alone. If the WG wants to publish an implementation guide
as an RFC, I need a
PaceFeedIdOrAlternate, withdrawn, no comment
PaceFeedIdOrSelf 0
PaceOptionalFeedLink +1
I agree with the rationale; no point making people things they can't do.
I'm assuming that if PaceOptionalFeedLink goes through feed:id is a MUST.
cheers
Bill
On 7/5/05 12:09 AM, Graham [EMAIL PROTECTED] wrote:
If an Atom Feed Document contains multiple entries with the same
atom:id, software MUST treat them as multiple versions of the same
entry
I don't think this changes the technical meaning of the proposal, but
does make it very explicit.
Graham wrote:
On 6 May 2005, at 2:10 pm, Dave Johnson wrote:
Yes, I think both of my arguments fail to hold and I no longer have a
real objection to duplicates. Allowing duplicates gives feed produces
to model events or other objects (versioned documents in a wiki) as
they wish. Like you, I
Hi Mark,
Like you, I am not short of things to do but would be willing to contribute to this process.
I guess the first thing to be clarified is whether the WG wants an Implementation Guide or not. Then, assuming they do, an idea of hoped-for timetable and scope would be good.
Since I have, on
On 6/5/05 11:51 PM, Mark Pilgrim [EMAIL PROTECTED] wrote:
In case this got buried in the previous thread, last fall I wrote but
never publicized a minimal draft of an Atom Implementation Guide.
http://diveintomark.org/rfc/draft-ietf-atompub-impl-guide-00.html
Due to my commitments
Bill de hÓra wrote:
PaceFeedIdOrAlternate, withdrawn, no comment
PaceFeedIdOrSelf 0
PaceOptionalFeedLink +1
I agree with the rationale; no point making people things they can't do.
I'm assuming that if PaceOptionalFeedLink goes through feed:id is a MUST.
On what do you base that assumption?
-
Sam Ruby wrote:
Bill de hÓra wrote:
PaceFeedIdOrAlternate, withdrawn, no comment
PaceFeedIdOrSelf 0
PaceOptionalFeedLink +1
I agree with the rationale; no point making people things they can't
do. I'm assuming that if PaceOptionalFeedLink goes through feed:id is
a MUST.
On what do you base
On 7/5/05 1:16 AM, Bob Wyman [EMAIL PROTECTED] wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that identify
On 5/6/05, Tim Bray [EMAIL PROTECTED] wrote:
So if you have a strong feeling, pro or contra, about any of the Paces
currently in play, please make sure you've put it on the record since
then.
PaceOptionalSummary addresses a last call issue. I expect every single
last call comment will be
Some have been clamoring for a good definition of an entry.
Here is one I have thought of recently.
An Atom Entry is a resource (identified by atom:id) whose
representations
(atom:entry) describe the state of a web resource at a time
(the link alternate)
Any thoughts?
Henry
On 5/6/05, Bob Wyman [EMAIL PROTECTED] wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that
On May 6, 2005, at 8:49 AM, Eric Scheid wrote:
Are they still the same entry if they have different source elements
that identify their source as being different feeds?
I don't see why. I subscribe to a Local News feed, a National News
feed, and
a Science News feed. All from the same publisher.
On 6 May 2005, at 4:16 pm, Bob Wyman wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source
elements
that identify their source
Nikolas 'Atrus' Coukouma wrote:
Using @rel with any linking element is perfectly valid and has been for
years.
@rel not being supported for anything other than the link element itself
has also been an outstanding bug for just as long. There's lot of debate
attached to at least one Mozilla bug
--On May 5, 2005 10:53:48 AM -0700 John Panzer [EMAIL PROTECTED] wrote:
I assume an HTTP Expires header for Atom content will work and play well with
caches such as the Google Accelerator (http://webaccelerator.google.com/).
I'd also guess that a syntax-level tag won't. Is this important?
Henry Story wrote:
An Atom Entry is a resource (identified by atom:id) whose
representations (atom:entry) describe the state of a web resource
at a time (the link alternate).
I think that if this is not 100% correct then it is at least very
close to whatever correct actually is.
On 6 May 2005, at 4:28 pm, Bill de hÓra wrote:
That there is consensus we'll want to identify a feed, even if we
can't provide a link.
I'd +1 an ordinary make feed:id required Pace.
PaceFeedIdOrSelf is too awful an idea for words.
Graham
Sjoerd Visscher wrote:
[HTML 4.01 says:] This attribute describes the relationship from
the current document to the anchor specified by the href attribute.
The value of this attribute is a space-separated list of link types.
But, if you copy HTML from one document to another, or you
Graham wrote:
On 6 May 2005, at 4:28 pm, Bill de hÓra wrote:
That there is consensus we'll want to identify a feed, even if we
can't provide a link.
I'd +1 an ordinary make feed:id required Pace.
I'd +1 any Pace that has a chance of achieving consensus that makes at
least one element that can
Thursday, May 5, 2005, 11:42:22 PM, Tim Bray wrote:
-1
Irrespective of whether I agree with this or not, I think the material
belongs in an implementor's guide, not the specification. -Tim
I'm a bit uncomfortable with punting yet another issue into the
Implementor's Guide when the WG has
On 5/6/05, Sam Ruby [EMAIL PROTECTED] wrote:
At the moment, alternate link is the element of record.
Do any applications use it as such? In my experience, applications use
the URI they retrieved the feed from as the feed identifier. For
example, I believe every single pubsub.com match feed
Bob Wyman wrote:
I've got another example of a selfish feed which is producing dynamic
content which will cause many duplicate entries to float around the
blogosphere. The feed in question here is an RSS feed. Nonetheless, I think
we must expect people will do the same stupid tricks with Atom
Sam Ruby wrote:
It seems to me that instead of adding a dynamic content flag, having
a separate id element (or in RSS 2.0's case, utilizing the guid
element) would be more to the point.
Relying on a GUID alone only works if you implement a policy that
says that you are only interested
Tim Bray wrote:
+1
I'm not 100% convinced it solves the problems Rob says it does, but it
seems cheap, lightweight, and unlikely to cause any harm. -Tim
I'm growing increasingly comfortable with the concept of allowing
redistributors to assign new ids as long as they track the original
(i.e.:
On Friday, May 6, 2005, at 09:16 AM, Bob Wyman wrote:
Graham wrote:
If an Atom Feed Document contains multiple entries with the
same atom:id, software MUST treat them as multiple versions of
the same entry
Are they still the same entry if they have different source elements
that identify
--On May 6, 2005 4:37:23 PM -0400 Bob Wyman [EMAIL PROTECTED] wrote:
Frankly, I really wish that we had done the blog architecture work
many months ago so that we would all have a shared understanding of the
system-wide issues and components rather than the widely divergent personal
On Thursday, May 5, 2005, at 05:21 PM, Robert Sayre wrote:
On 5/5/05, Antone Roundy [EMAIL PROTECTED] wrote:
Yeah, they think they are, or at least claim to think so. But isn't
that the same thing that is stated if you see the following in two
feeds?
feed
idbar:bar/id
entry
-1. Having two mechanisms in two different layers is a recipe for
disaster. If HTTP headers are good enough for everything else on the
web, they're good enough for Atom.
--Paul Hoffman, Director
--Internet Mail Consortium
Friday, May 6, 2005, 5:46:59 PM, you wrote:
Some have been clamoring for a good definition of an entry.
Here is one I have thought of recently.
An Atom Entry is a resource (identified by atom:id) whose
representations
(atom:entry) describe the state of a web resource at a time
(the
Nikolas 'Atrus' Coukouma wrote:
Using @rel with any linking element is perfectly valid and has been for
years.
@rel not being supported for anything other than the link element itself
has also been an outstanding bug for just as long. There's lot of debate
attached to at least one Mozilla bug
Is there something wrong with the HTML parsers?
Nikolas: Are they installed by default on most servers? If not, can
those running in sandboxes install them?
From the perspective of my niche, I can tell you that Coldfusion can
use jTidy to make sense of random HTML, but it is (a) installed in
58 matches
Mail list logo
