On 10/4/05 12:52 AM, Eric Scheid [EMAIL PROTECTED] wrote:
could it be reasonable that an empty element gets displayed as empty, but an
absent element triggers a fall back mechanism (eg. use the summary
element, and if that is missing display the link rel=alternate resource?
The first RSS
* James Aylett [EMAIL PROTECTED] [2005-04-10 11:55]:
On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote:
* the atom:entry contains an atom:content that has a src
attribute (and is thus empty).
FWIW, for clarity I would favour:
'... has a src attribute (and is thus itself
Sam Ruby wrote:
Robert Sayre wrote:
I want the to know the precise technical reason for these requirements.
First, I'd like to ask a favor. Please wait 24 hours before replying to
this email.
No.
In your zeal to filibuster on this particular topic,
Filibuster? What am I trying to delay? I've
No one agrees with you Robert. Quit it.
Graham
--On April 8, 2005 8:29:52 PM -0400 Robert Sayre [EMAIL PROTECTED] wrote:
Please don't respond to me by saying that accessibility is important.
I would never say that. Required or essential, but not merely important.
wunder
--
Walter Underwood
Principal Architect, Verity
Graham wrote:
No one agrees with you Robert. Quit it.
I suppose then I should state I'm very close to +1 on Robert's position.
I think this is an important discussion, insofar as whether the link or
the content is primary stuff, and I wouldn't to see it cut short because
it became another
* Sam Ruby [EMAIL PROTECTED] [2005-04-09 22:30]:
What compelling use case would enabling the omission of
non-remote, textual content - i.e., not merely providing a zero
length content, but the outright omission of same - enable?
I have no opinion either way (not that it would have much
On Apr 9, 2005, at 4:26 PM, Graham wrote:
No one agrees with you Robert. Quit it.
Well, Robert has not actually favored us with a single clear sentence
expressing his point, so I'll try:
The requirement on accessibility grounds for a required atom:summary
is superfluous, because we have
The requirement on accessibility grounds for a required
atom:summary is superfluous, because we have atom:title and one
required text field is enough.
There's another solution compatible with this, which is to make title
optional (which I've always supported). In most title only feeds, the
Walter Underwood wrote:
--On Friday, April 08, 2005 01:33:20 AM -0400 Robert Sayre
[EMAIL PROTECTED] wrote:
Accessibility is a non-starter absent expert opinion or substantially
similar formats. Frankly, the notion that remote content constitutes an
accessibility concern is absurd. Might as well
--On April 8, 2005 6:59:47 PM -0400 Robert Sayre [EMAIL PROTECTED] wrote:
Walter, you are missing my point. You've said it yourself:
Maybe summaries are optional, but not because accessibility is optional.[0]
That was in reply to a proposal to make accessibility an optional profile, and
to
Walter Underwood wrote:
Local textual summaries are rather common on the web. The a tag, for example.
Current accessibility practice is to make the anchor text understandable out
of context. In other words, to make it a summary of the linked resource.
Even if the remote resource is text!
For the
Sam Ruby wrote:
If, instead, it opens the door for multiple changes without explicit
rationale; at the last minute; overturning carefully formed consensus;
then it was not.
Uh, so your changes are ok, but mine aren't? We continue the lovely
pattern of DOSing proposals.
I am willing to go with
Robert Sayre wrote:
Sam Ruby wrote:
If, instead, it opens the door for multiple changes without explicit
rationale; at the last minute; overturning carefully formed consensus;
then it was not.
Uh, so your changes are ok, but mine aren't? We continue the lovely
pattern of DOSing proposals.
Sam Ruby wrote:
At this point, small surgical changes to address specific concerns may
(or may not) be acceptable. Wholesale changes with little rationale are
less likely to be so.
Well, who really cares anyway. I'll get the draft ready. Nobody propose
any 'wholesale changes' in the meantime,
Robert Sayre wrote:
Sam Ruby wrote:
Content remains optional.
The pace did not drop the requirement for a link element in the absence
of content.
OK, I missed that. What else did I miss at this late date?
As it stands, this Pace declares co-constraints bad, selectively removes
a few
On Apr 6, 2005, at 8:45 PM, Robert Sayre wrote:
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are incorrect. There was an extended discussion, with Mark
Pilgrim steadfastly refusing to let the hideous old
multipart/alternate go until we had another proposal
Tim Bray wrote:
Actually, the argument was that if the content is either non-textual or
remote, a summary is beneficial to accessibility. I agree that many
people made this argument, sufficient in the co-chairs' minds to
establish rough consensus.
I understand the argument if the content is
Robert Sayre wrote:
Sam Ruby wrote:
At this point, small surgical changes to address specific concerns may
(or may not) be acceptable. Wholesale changes with little rationale
are less likely to be so.
Well, who really cares anyway. I'll get the draft ready. Nobody propose
any 'wholesale
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
Yeah, but we can't really legislate that, can we? We are making
editorial decisions for publishers via validity constraints.
You have made a
On Apr 7, 2005, at 2:22 PM, Robert Sayre wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
Yeah, but we can't really legislate that, can we? We are making
editorial decisions for publishers via validity
* Robert Sayre [EMAIL PROTECTED] [2005-04-07 17:22-0400]
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
+1
Yeah, but we can't really legislate that, can we? We are making
Dan Brickley wrote:
* Robert Sayre [EMAIL PROTECTED] [2005-04-07 17:22-0400]
Sam Ruby wrote:
Whether it is for accessibility, or for general usability, I want to
ensure that every entry has a textual, non-remote component to it.
+1
Yeah, but we can't really legislate that, can we? We are
Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceCoConstraintsAreBad
Abstract
Require atom:id, atom:title, atom:updated, atom:author. That's it.
Status
Open
Rationale
The spec delivers value when it can make an
Sam Ruby wrote:
co-constraints are bad.
Entries without either a summary or content or even a link to where you
can find the data are worse.
Does my Pace allow such a creature?
Robert Sayre
Robert Sayre wrote:
Sam Ruby wrote:
co-constraints are bad.
Entries without either a summary or content or even a link to where
you can find the data are worse.
Does my Pace allow such a creature?
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a
Sam Ruby wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint, and we fail to meet the requirements of our charter for any
On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are incorrect. There was an
Tim Bray wrote:
On Apr 6, 2005, at 8:04 PM, Robert Sayre wrote:
This pace dropped the requirement for an alternate link. This pace
dropped the requirement for a summary when content is not present.
Yes, because the WG has *never* voiced an opinion in favor of that
constraint,
You are
On Wednesday, April 6, 2005, at 08:40 PM, Sam Ruby wrote:
My order of preference:
PaceFeedIdOrAlternate
PaceFeedIdOrSelf
Current Text
PaceCoConstraintsAreBad
To summarize what elements would be required under each, all four
require atom:title and atom:updated. Additionally:
Current
30 matches
Mail list logo
