Subject: Re: Don't bake discrimination into the Atom core (was Re: Low-hanging fruit: multipart/alternative)

From: Graham <[email-masked]>
Date: Wed, 14 Jul 2004 23:36:38 -0400

Mark Pilgrim wrote:

> The current design allows inaccessible content *and* accessible
> alternatives.  Tim is recommending removing multipart/alternative but
> *not* simplifying the content model.  This would leave the spec in a
> state that publishers with a way to publish inaccessible content, but
> no way to publish accessible alternatives, which is unacceptable.

<title>? <summary>? Can't the accessible content go in there? Summary 
especially seems like a good place for, say, a textual description of a 
picture or movie - it might even be the right place as well. Granted, 
inaccessible content can be placed in all three, but saying there's no 
place for alternate content is an outright lie.

+1 to PaceNukeMultipart. I'm shocked it ever got in.

Graham

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 15 Jul 2004 09:03:29 -0400

> place for alternate content is an outright lie.

That's not what title or summary are for.  Specifically, <title> "is a
Content construct that conveys a human-readable title for the entry." 
This is not the place for accessible alternate content.

<summary> "is a Content construct that conveys a short summary,
abstract or excerpt of the entry."  This is not the place for
accessible alternate content either.

I'm shocked, shocked that you, an aggregator developer of some note,
should recommend overloading core elements with different meanings. 
Didn't you complain about that wrt. some other format?  My memory is
fuzzy.  Or maybe it's all the outright lying I've been doing.  It
tends to get in the way of productive discussion.

-- 
Cheers,
-Mark

---

From: Graham <[email-masked]>
Date: Thu, 15 Jul 2004 12:00:43 -0400

> accessible alternate content either.

It may not be "what it's for", but I don't see why accessible content 
is incompatible with it. Furthermore, could you stop advocating for 
five seconds and tell us what it is you want? You're the expert.

Graham

---

From: Mark Pilgrim <[email-masked]>
Date: Thu, 15 Jul 2004 13:17:46 -0400

> five seconds and tell us what it is you want? You're the expert.

1. I want you to stop yelling at me.
2. I want someone to withdraw PaceNukeMultipart.
3. I want language in the spec that recommends that publishers who
link to inaccessible content also link to accessible alternatives.  I
will write up a Pace for this.
4. I want to wait until we decide whether we're going to simplify the
content model before making any further decisions on accessible
alternate content.  If Content constructs can only include (X)HTML or
plain text, that simplifies the accessibility picture enormously.
5. I want to go read http://www.w3.org/TR/xag (thanks Matt) to see
what else I haven't thought of.

-- 
Cheers,
-Mark

---

From: Dave Pawson <[email-masked]>
Date: Thu, 15 Jul 2004 19:37:41 +0100

On Thu, 2004-07-15 at 17:00, Graham wrote:
> is incompatible with it.

A little bit high horse, but if it makes the point.
Assume you lose one of your relevant senses.
  You have the construct you proposed.
  Two channels are offered,
  A 2 minute video of whatever or
  A two line <summary>.
  I don't see any equality there?

  Just on semantic grounds, how might a 'summary' equate in terms of
information transmission to that video?

  If an author wants to publish an image, a video, an audio clip,
   let them offer equivalents.
   <mediaobject>
     <video src=' />
     <text>
        structured text alternative
     <whatever you feel like offering/>
   </mediaobject>

Not advocating that syntax, but to me that reads like viable equal
offerings. 

Regards DaveP.
XSLT&Docbook  FAQ
http://www.dpawson.co.uk/xsl

---

From: Ken MacLeod <[email-masked]>
Date: 15 Jul 2004 14:44:33 -0500

I've updated PaceSimpleContentType.  A summary of what this Pace now
covers:

 * constrains the general use of the Content construct to inline XML
   text (markup or characters), as used for <name>, <title>,
   <tagline>, <copyright>, <info>, and <summary>.

 * includes spec text for the known profiles of inline representations

 * removes @type from the general Content construct, and removes
   base64 as @mode.

 * allows <content> to have a @src and @type, and only allows one
   <content> as the content with the most faithful representation of
   the content (MIME terminology there)

 * <content> can only be inline or @src, because

 * added a <content-alternate> element for alternate full body
   contents, it shares the element content model of atom:content.

Things I considered when updating this:

 * atom:summary might be a summary representation (thumbnail, short
   clip) of atom:content, and should also allow @src and @type, which
   means,

 * a corresponding atom:summary-alternate element, which would lead to,

 * possibly generalizing the Content-by-reference construct, and

 * moving "alternate" in as a type of attribute (not @rel!) of the now
   generalized Content-by-reference construct.

Thoughts?

  -- Ken