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

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 15:19:01 -0400

"We can discuss replacing the syntax with something better, but we can't 
simply remove the functionality."

We can do whatever we want in a working draft. I don't understand why 
the continued inclusion of a totally busted feature is a win for 
accessibility.

Robert Sayre

Robert Sayre wrote:

> 
> Mark Pilgrim wrote:
> 
>> Also note that I am not a fan of the type="multipart/alternative"
>> syntax or design.  But getting rid of it without an
>> accessibility-enabled alternative is much worse.  We can discuss
>> replacing the syntax with something better, but we can't simply remove
>> the functionality.
>>  
>>
> 
> What's the use case here? If we remove multipart/alternative, 
> inaccessible content will still be surrounded by plain text or HTML 
> metadata, and could still have a variety of <link rel="alternate"> 
> elements that point to other representations (could be in the same 
> feed). Can we improve on this, or do we just need to be more explicit 
> about alternate representations?
> 
> I don't see mulitpart/alternative helping with photographs, for instance.
> 
> Robert Sayre
>

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 15:35:32 -0400

> the continued inclusion of a totally busted feature is a win for

First, it's not "totally busted," that's a flame and it's simply
wrong.  It is almost universally unimplemented, as is base64 and a few
other things about our current content model, which is why we
currently have three Paces proposing various ways to simplify it.

Second, I don't see the logic in removing functionality from a working
draft "since it's apt to confuse people coming newly to Atom and
reading our drafts."  (That's a quote from Tim in another thread from
this morning.)  I thought these drafts were only for discussion, not
for deployment.  Fine, let's discuss simpler content models.  Leave
the newbies to fend for themselves for now.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 15:43:07 -0400

Mark Pilgrim wrote:

> wrong.  

If I have a feed containing base64 video (why...), and I update a 
transcript in an alternate content element, then all those aggregators 
using conditional GET will refetch everything. It's broken.

> It is almost universally unimplemented, as is base64 and a few

Perhaps we can reframe this debate. Is there any reason multiple content 
constructs are superior to well-titled alternate links?

Robert Sayre

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 15:54:48 -0400

> using conditional GET will refetch everything. It's broken.

News flash: HTTP is dumb.  If someone publishes a 250 KB feed of text
entries and then adds another entry, all those aggregators using
conditional GET with refetch everything.  (Think this doesn't happen? 
We have a hardcoded 200 KB limit on the feed validator.  People *who
are conscientious enough to validate* hit it all the time.)

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 16:22:25 -0400

> are conscientious enough to validate* hit it all the time.)

You seem to be reinforcing my position?

Once again, I'll ask you why linking to alternate representations of the 
entry is insufficient:

I don't see multipart/alternative helping with photographs, for instance.

Robert Sayre

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 16:32:14 -0400

> You seem to be reinforcing my position?

No, I'm pointing out that your "position" has nothing to do with the
topic at hand.  We're not going to solve the delta-HTTP problem today.
 (There's an RFC for that somewhere.  BillK will find it.)

> Once again, I'll ask you why linking to alternate representations of the

It's not granular enough.  Atom entries can currently contain multiple
content elements (regardless of multipart/alternative).  Accessibility
requires a way to say that *this* is an accessible alternative to
*that*.  Entry-level alternate representations are not granular enough
if each entry can contain multiple distinct pieces of content.  You
need content-level alternates.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 16:44:49 -0400

Mark Pilgrim wrote:

> content elements (regardless of multipart/alternative).  

Would linking be granular enough given the following constraints?

title & summary must be HTMl/XHTML/TEXT
one content element per entry (does anybody use multiple content elements?)

Robert Sayre

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 31 Aug 2004 16:54:07 -0400

> one content element per entry (does anybody use multiple content elements?)

Yes.

I do not know of anyone currently using multiple content elements.  I
believe one of the original use cases was delivering an (inline) photo
along with a (text or HTML) caption, each in its own content element. 
And similarly in reverse (uploading photos with captions).  That use
case seems to have dissipated with the other SimpleResourcePosting
discussion, so maybe nobody needs multiple content elements.

Note that you have strayed far, far away from the original topic,
which was "let's get rid of <content type="multipart/alternative"> and
replace it with nothing."  You have brought in bits and pieces of
several different proposals, including some that are under active
discussion in other threads at the moment.

Accessibility is not just one thing, and it is not isolatable.  It
needs to be considered as part of every proposal, especially
content-related proposals.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 17:10:11 -0400

> replace it with nothing."

No, it was just "let's get rid of it," and we'll figure out a better way 
to deal with it. The chair specifically stated so.

> You have brought in bits and pieces of

Hey, I got you to approve of an approach. I'm happy with that.

> content-related proposals.

Since you are an expert on this topic, the group looks to you for 
guidance here. It would be helpful if you commented more extensively on 
these matters. Emails consisting of nothing but "-1" for editorial 
reasons confuse everybody.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 31 Aug 2004 19:20:34 -0700

>> one content element per entry (does anybody use multiple content 

+1.  And thank you, Rob, for working through this.  -Tim