On May 18, 2005, at 6:19 PM, Sam Ruby wrote:
Isn't that redundant? From PaceOptionalSummary:
Yup. Think we got that covered. -Tim
Robert Sayre wrote:
On 5/18/05, Graham <[EMAIL PROTECTED]> wrote:
On 18 May 2005, at 9:36 pm, Robert Sayre wrote:
atom:entry elements are advised to contain ... a non-empty
atom:summary element when the entry
contains no atom:content element
I'd like us to advise including an atom:summary when atom
On Wednesday, May 18, 2005, at 10:11 AM, Sam Ruby wrote:
There seemed to be consensus that feeds needed something to
identify
them. What there wasn't consensus on is which element should be
that identifier. The solution selected was to make none of the
identifiers required - som
On 5/18/05, Graham <[EMAIL PROTECTED]> wrote:
> On 18 May 2005, at 9:36 pm, Robert Sayre wrote:
>
> > atom:entry elements are advised to contain ... a non-empty
> > atom:summary element when the entry
> > contains no atom:content element
>
> I'd like us to advise including an atom:summary when a
On Wednesday, May 18, 2005, at 03:17 PM, Henri Sivonen wrote:
On May 17, 2005, at 17:47, Antone Roundy wrote:
What possible advantage would there be to allowing just anyone to add
elements to Atom's namespace, or any other namespace, for that
matter? I can't think of any.
If you add to an exist
Eric: My bad... I was looking at Ye Olde PaceDateModified, not
PaceDateModified2. Template-based systems can't reliably produce a
PaceDateModified, but PDM2 is a different story.
Consider the -1 moved to +0.
--
Roger Benningfield
Tim Bray wrote:
PaceEntryState
Rejected, no support.
Wasn't it intended for the protocol spec? (though section 3.5 doesn't
exist in protocol-04)
PaceOptionalXhtmlDiv
A handful of -1's, no support, rejected.
Maybe it came a bit late? And I think the -1's were misinterpretations
of the Pace.
None
On 18 May 2005, at 6:03 pm, Robert Sayre wrote:
Missed one:
- There are many applications and users that *don't want* summaries.
Some examples include Firefox, Cellphones, Tivos
What happens when FireFox expands their Atom support to show
summaries, but everyone's subscribed to title-only feeds?
* Graham <[EMAIL PROTECTED]> [2005-05-18 23:15]:
> On 18 May 2005, at 9:36 pm, Robert Sayre wrote:
>> Regardless of how an associated application will handle
>> entries with no atom:summary element, all Atom Processors MUST
>> NOT fail to process Atom entries simply because they contain
>> no atom
On May 17, 2005, at 17:47, Antone Roundy wrote:
What possible advantage would there be to allowing just anyone to add
elements to Atom's namespace, or any other namespace, for that matter?
I can't think of any.
If you add to an existing namespace, you don't need to add confusing
namespace decla
On 18 May 2005, at 9:36 pm, Robert Sayre wrote:
atom:entry elements are advised to contain ... a non-empty
atom:summary element when the entry
contains no atom:content element
I'd like us to advise including an atom:summary when atom:content is
binary (or for that matter, any non-text/html/xhtm
Robert Sayre wrote:
How about this:
Some applications may choose to require a minimum amount of inline
text or (X)HTML data to function reliably and predictably. For that
reason, atom:entry elements are advised to contain a non-empty
atom:title element, a non-empty atom:summary element when the ent
> PaceDuplicateIDWithModified
> The consensus of the group against atom:modified months and months
> ago was quite strong and this is not enough momentum to accomplish
> such a major policy reversal. Rejected.
I don't think that this Pace has had enough discussion to be rejected
just yet - it's
On 5/18/05, Sam Ruby <[EMAIL PROTECTED]> wrote:
> A concrete example of my concern is that feeds with atom:entries
> containing will have those entries omitted by Firefox's
> livebookmark support.
>
> The proposed changes to sections 3.1.1.1, 3.1.1.2, and 3.1.1.3, apply to
> all text constructs
Wednesday, May 18, 2005, 1:16:15 PM, Roger B wrote:
>> There was opposition to atom:modified because we couldn't see a need for it.
>> Now we have a need for it.
> Eric: That most definitely wasn't the core reason for opposition, to
> my recollection.
I just checked the PaceDateModified thread
Graham wrote:
On 18 May 2005, at 6:03 pm, Robert Sayre wrote:
Missed one:
- There are many applications and users that *don't want* summaries.
Some examples include Firefox, Cellphones, Tivos
What happens when FireFox expands their Atom support to show
summaries, but everyone's subscribed to tit
Robert Sayre wrote:
I broadly agree with the chairs' opinions.
Tim Bray wrote:
PaceTextShouldBeProvided
+1 from Ruby, explicit -1's from Sayre and de hÓra. However, taking
this and PaceOptionalSummary together, it seems clear that the WG
generally believes the following:
- Title-only feeds a
* Tim Bray <[EMAIL PROTECTED]> [2005-05-18 06:30]:
> This was modified in the course of debate. It can't be accepted
> because the +1's (and -1's too) were referring to multiple different
> wordings and there were three pretty strong -1's.
>
> Conclusion: The editors are asked to strengthen th
On 5/18/05, Graham <[EMAIL PROTECTED]> wrote:
> On 18 May 2005, at 6:03 pm, Robert Sayre wrote:
>
> > Missed one:
> > - There are many applications and users that *don't want* summaries.
> > Some examples include Firefox, Cellphones, Tivos
>
> What happens when FireFox expands their Atom support
On 5/18/05, Tim Bray <[EMAIL PROTECTED]> wrote:
> Yeah, in the case of XML, having the notion of an XML processor allowed
> us to describe some real important things that turned out to be hard to
> describe any other way. My personal opinion is that the benefit of
> defining this in the Atom cas
On May 18, 2005, at 10:03 AM, Robert Sayre wrote:
However, the absence of
atom:summary is not an error and software MUST NOT fail to function
correctly as a consequence of such an absence."
We don't use the term 'software' in the draft. We discuss Atom
Processors.
Oops, editorial issue, please main
Antone Roundy wrote:
This is already bad enough. Now how about if the phishing feed claims
that it's atom:id is http://a.com/feeda. Worse still. With the current
spec text, an Atom consumer that does a little extra work, somehow
figures out that the phishing version of the entry is not the sa
I broadly agree with the chairs' opinions.
> Tim Bray wrote:
>>
>>
>> PaceTextShouldBeProvided
>>
>> +1 from Ruby, explicit -1's from Sayre and de hÓra. However, taking
>> this and PaceOptionalSummary together, it seems clear that the WG
>> generally believes the following:
>>
>> - Title-
--On Thursday, May 19, 2005 01:12:22 AM +1000 Eric Scheid <[EMAIL PROTECTED]> wrote:
(See the wiki for a survey of tools and the dates they support.)
hmmm ... Blogger, Moveable Type, JournURL, bloxsom, ExpressionEngine,
ongoing, Roller, Macsanomat, WordPress, and BigBlogTool all provide dates
which
Sam Ruby wrote:
Tim Bray wrote:
On behalf of Paul and myself.
Atom issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList
The volume of correspondence was unfortunately high for an IETF Last
Call that came after a Working Group Last call. It is quite possible,
as always, that the co
On Wednesday, May 18, 2005, at 09:12 AM, Henry Story wrote:
I supposed the surest way to make it impossible to fake the id, is to
specify that
by dereferencing the id and doing a GET (whatever the correct method
of doing that for the
protocol happens to be) one should be able to retrieve the ent
On 18/5/05 10:16 PM, "Roger B." <[EMAIL PROTECTED]> wrote:
> Eric: That most definitely wasn't the core reason for opposition, to
> my recollection. It was opposed because it can't be reliably produced
> by existing systems, among other things.
The exact same argument can be made against atom:pu
On 18/5/05 7:41 PM, "Graham" <[EMAIL PROTECTED]> wrote:
>> Some are content changes, or metadata changes.
>
> I see no discussion of this distinction in the atom:modified proposal.
I meant "content or metadata changes". I don't care so much about the
distinction between those two senses. I was h
On 18 May 2005, at 16:41, Antone Roundy wrote:
On Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote:
"If multiple atom:entry elements with the same atom:id value
appear in an Atom Feed document, they describe the same entry and
software MUST treat them as such."
IIRC, much of this started d
On Tuesday, May 17, 2005, at 11:07 PM, Sam Ruby wrote:
"If multiple atom:entry elements with the same atom:id value appear
in an Atom Feed document, they describe the same entry and software
MUST treat them as such."
IIRC, much of this started due to an objection by Bob Wyman that
treating atom
> There was opposition to atom:modified because we couldn't see a need for it.
> Now we have a need for it.
Eric: That most definitely wasn't the core reason for opposition, to
my recollection. It was opposed because it can't be reliably produced
by existing systems, among other things. (See the
On 18 May 2005, at 6:01 am, Eric Scheid wrote:
Not so very long ago you suggested that aggregators look at the
content to
determine if it's changed. If it's good enough for aggregators,
it's good
enough for publishers (actually better than good enough since the
publisher
would be able to do t
Tim Bray wrote:
Conclusion: This Pace is rejected. However, the editors are directed to
include the following text in 4.2.13:
"Experience teaches that feeds which contain textual content are in
general more useful than those which do not. There are certain classes
of application, for example
33 matches
Mail list logo
