Uh, this one is redundant, right? It's covered by various combinations
of other Paces, or am I missing something? -Tim
* 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
On Sat, Apr 09, 2005 at 11:06:00PM -0400, Robert Sayre wrote:
[Text proposal]
> The 10th bullet point of section 4.1.2 should read:
>
> atom:entry elements MUST contain an atom:summary element in either of
> the following cases:
>
> * the atom:entry contains an atom:content that has a "src
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
> element, and if that is missing display the resource?
The first RSS Reader I used (SharpRea
On 10/4/05 1:06 PM, "Robert Sayre" <[EMAIL PROTECTED]> wrote:
> An app would handle an empty content element the same way it would an
> absent one.
would it?
could it be reasonable that an empty element gets displayed as empty, but an
absent element triggers a fall back mechanism (eg. use the
Sam Ruby wrote:
Hi Roger! Yes, I recall you constructively participating in when this
was discussed previously, and consensus was declared on the issue by the
co-chairs:
Ah, a process argument. If the chairs consider this discussion out of
order, they can declare it so. I will respect that.
Tim Bray wrote:
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 10th bullet point of section 4.1.2 should read:
atom:entry elements MUST contain an atom:s
"The requirement on accessibility grounds for a required
is superfluous, because we have 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
title is usually word
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
is superfluous, because we have and one required t
* 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
we
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 syndica
--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
No one agrees with you Robert. Quit it.
Graham
Roger B. wrote:
The few cases I have seen where there have been feeds which (briefly)
have not had so much as a summary, there always has been a swift and
clear response by the consuming public.
Sam: In the case of the no-content feeds I've produced over the last
few years, the response from the pu
> The few cases I have seen where there have been feeds which (briefly)
> have not had so much as a summary, there always has been a swift and
> clear response by the consuming public.
Sam: In the case of the no-content feeds I've produced over the last
few years, the response from the public has
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
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. In your zeal to filibuster on this particular topic, you
have made a number of fallacious and personal attacks.
- -
Walter Underwood wrote:
Local textual summaries are rather common on the web. The 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 ta
--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,
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 wel
--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 write off the whole Web.
Tim Bray wrote:
You are implying that would be somehow inappropriate or
unsportsmanlike. It isn't. If there is consensus, such a challenge
would be squashed rather quickly, don't you think?
Just for the record, I strongly agree that Atom entries should be
required to include (to use Sam's words
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 ma
* 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 mak
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 c
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 num
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 changes
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 non
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
s not.
My order of preference:
PaceFeedIdOrAlternate
PaceFeedIdOrSelf
Current Text
PaceCoConstraintsAreBad
"no one has spoken up in favor of the current text" remains true.
I am willing to go with PaceFeedIdOrSelf. A number of people have
expressed support for it. I don
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, O
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.
Unfair
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 P
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 Text
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 incorrect
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 ex
element,
feeling that we might be able to come to an agreement on that. This
appears to have been a tactical error...
Strawmen are usually tactical errors.
My order of preference:
PaceFeedIdOrAlternate
PaceFeedIdOrSelf
Current Text
PaceCoConstraintsAreBad
"no one has spoken up in fa
al error as it was immediately followed by
a pace that changed one word and added twenty one, affecting two
elements. Now you introduce a pace that changes the definition of three
elements.
My order of preference:
PaceFeedIdOrAlternate
PaceFeedIdOrSelf
Current Text
PaceCoConstraintsAreBad
- Sa
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:
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 ma
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 element mand
42 matches
Mail list logo
