Mark Pilgrim wrote:
On 5/19/05, Tim Bray <[EMAIL PROTECTED]> wrote:
[atom:summary and accessibility]
Right now our draft says:
atom:entry elements MUST contain an atom:summary element in any of the following cases: ... - the atom:entry contains an atom:content that has a "src" attribute (and is thus empty). - the atom:entry contains content that is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [MIMEREG] and does not begin with "text/" nor end with "+xml".
I'm saying that "MUST" is probably too strong here. I don't mind it personally, but I don't see the case for requiring it on grounds of interoperability. If we keep it, the format spec should probably mention *why* this is required, if only in passing.
+1
Particulary on the first point above "atom:content that has a "src" attribute", "MUST" is a bit heavy handed for accesibility, since the "src" attribute could reference an accessible resource - like an external html file. Its when "src" references an inaccessible resource is it essential that atom:summary convey an accessible equivalent.
The second point about Base64 encoding, "MUST" or "strongly recommended/encouraged for the purpose of accessibility" is needed.
In respect to Mark's suggestion of mentioning why:
Perhaps "4.2.13 The "atom:summary" element" is a good place to mention the accessibility. As an initial suggestion, after the first paragraph of
"The "atom:summary" element is a Text construct that conveys a short summary, abstract or excerpt of an entry."
Insert the paragraph:
" In cases where atom:content is Base64 encoded, or has a "src"
attribute, the atom:summary conveys an accessible text equivalent
to the non-text atom:content."Then again, if it got changed to "SHOULD", I wouldn't raise holy hell about it. But I'm not going to write a Pace to change it.
That suits me fine too.
Thanks, Mike
