On 18/5/05 7:41 PM, Graham [EMAIL PROTECTED] 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
Tim Bray wrote:
On May 18, 2005, at 6:19 PM, Sam Ruby wrote:
Isn't that redundant? From PaceOptionalSummary:
Yup. Think we got that covered. -Tim
Off list, Robert pointed out to me that that the spec text I cited
didn't cover empty summaries. He's right.
- Sam Ruby
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 are OK for data where that's really all you have.
- Failing to
Graham 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:content is
binary (or for that matter, any
On 5/19/05, Isofarro [EMAIL PROTECTED] wrote:
I'd urge that the wording here should also include accessibility
concerns, especially to encourage accessible alternatives to to be
adopted when the content is known to be inaccessible - e.g. images,
sound files, movies, flash.
HTML for
On May 18, 2005, at 9: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 - something I
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 entry
contains no atom:content
On 5/19/05, Tim Bray [EMAIL PROTECTED] wrote:
co-chair-mode
Paul and I consider that the following text has consensus support of
the WG and the editors are directed to include it in the format draft
(editorial judgment call on where to insert):
Some applications (one example is full-text
---
The editors are directed to modify
the phrase which starts If multiple atom:entry elements... as
follows:
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.
I don't think we ever resolved this last call issue.
http://www.imc.org/atom-syntax/mail-archive/msg14383.html
Tim Bray wrote:
OK, WG, what do you think? I have long supported the SHOULD here, but
I can't help observing that a lot of different parties have
questioned it, I'm not 100% sure
Tim Bray wrote:
On May 18, 2005, at 9: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 -
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote:
Of course, breaking any link in my complicated chain of logic above
would cause the whole argument to collapse, which would be fine with me.
Maybe the requirement is useless.
If multiple atom:entry elements with the same atom:id value appear in
/ Sam Ruby [EMAIL PROTECTED] was heard to say:
| What should we do? One way to solve this is to require id *and* update
| Graham's original proposal accordingly, *and* incorporate it into the next
| (and presumably final draft).
|
| - - -
|
| That's what I meant by There is a danger of looking
/ Tim Bray [EMAIL PROTECTED] was heard to say:
| co-chair-mode
| Paul and I consider that the following text has consensus support of the WG
| and the editors are directed to include it in the format draft (editorial
| judgment call on where to insert):
|
| Some applications (one example is
On 5/19/05, Sam Ruby [EMAIL PROTECTED] wrote:
Graham Park has proposed that we loosen the existing language to
permit duplicate ids in the case where the entries have atom:source
elements which identify different URI's in self links. I support
this compromise and believe it
Rephrasing slightly...
+ 1
--
Roger Benningfield
On 19 May 2005, at 9:38 pm, Sam Ruby wrote:
What should we do? One way to solve this is to require id *and*
update Graham's original proposal accordingly, *and* incorporate it
into the next (and presumably final draft).
The original proposal actually relied on ids:
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate
On Thursday, May 19, 2005, at 06:41 AM, Tim Bray wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate agreement
On 19 May 2005, at 2:07 pm, Tim Bray wrote:
Some applications (one example is full-text indexers) require a
minimum amount of text or (X)HTML to function reliably and
predictably. For that reason, it is advisable that each atom:entry
element contain a non-empty atom:title element, a
On Thursday, May 19, 2005, at 09:41 PM, Eric Scheid wrote:
I see this as a problem...
4.1.2 The atom:entry Element
* atom:entry elements MUST contain exactly one atom:author element,
unless
the atom:entry contains an atom:source element which contains an
atom:author
element, or, in an Atom
On 20/5/05 2:10 PM, Antone Roundy [EMAIL PROTECTED] wrote:
If we do allow multiple authors, we might want to put a warning in that
consuming applications MAY ignore some of them if more than one is
supplied. As long as we do that, and perhaps even if not, I'd be in
favor of allowing more
22 matches
Mail list logo
