Subject: Low-hanging fruit: multipart/alternative

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 15:11:54 -0700

I don't think we have consensus on what we're replacing it with, but I 
think that we do have consensus that the description of 
multipart/alternative in 4.13.10 in draft-format-00 should go.  This 
was my take-way from the Atom Community meeting back in June -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Jul 2004 15:42:46 -0700

+1

--
Mark Nottingham     http://www.mnot.net/

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 13 Jul 2004 20:54:05 -0400

> was my take-way from the Atom Community meeting back in June -Tim

+1.  How about a single element called <choice>?

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 18:02:37 -0700

> +1.  How about a single element called <choice>?

Actually, I thought we'd nuked the whole notion of 
multiple-alternative-representations-of-the-entry, so the idea would be 
to just lose multipart/alternative.  But it's possible I have the wrong 
recollection... -Tim

---

From: Mark Pilgrim <[email-masked]>
Date: Tue, 13 Jul 2004 22:18:12 -0400

> to just lose multipart/alternative.  But it's possible I have the wrong

Well, I wasn't at that face-to-face meeting, and I don't recall us
discussing it on-list.  I wouldn't call it "low-hanging" to nuke it
permanently.

-- 
Cheers,
-Mark

---

From: Tim Bray <[email-masked]>
Date: Tue, 13 Jul 2004 19:46:58 -0700

> discussing it on-list.  I wouldn't call it "low-hanging" to nuke it

Good enough, we were pretty solid in the room but that was the room and 
this is the mailing list, which is official, it isn't low-hanging if 
there's discomfort, so MNot, if you'd already nuked that, you'd better 
de-nuke.   Could someone take ownership of writing a three-line Pace 
saying

"Nuke multipart/alternative for substantial cost and lack of a 
compelling use-case."

Thanks in advance. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 18:50:53 +0200

On Tue, 13 Jul 2004 19:46:58 -0700, Tim Bray <[email-masked]> wrote:

> Could someone take ownership of writing a three-line Pace saying
>

Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 18:46:37 +0200

> discussing it on-list.  I wouldn't call it "low-hanging" to nuke it

I agree on the «permanently» part, but removing the current description of  
multipart/alternative would imho be a good thing. If we come up with some  
brilliant solution in the future, we can always just squeeze that into the  
specification, right?

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 14 Jul 2004 13:08:24 -0400

> Done: <url: http://intertwingly.net/wiki/pie/PaceNukeMultipart>.

-1 on nuking it without an alternative proposal in place.  Atom's
current content model allows inline content of arbitrary type.  This
includes binary content (such as images) that are intrinsically
inaccessible to people with certain disabilities.  As long as Atom
allows for such inaccessible content to be published within a feed, I
absolutely positively insist -- with my last dying breath -- that we
have some mechanism for allowing publishers to include accessible
alternatives in the same feed, in a way that makes it clear that
*this* is an accessible alternative to *that*.

If you thought I was passionate about certain issues before, you ain't
seen nothin' yet.

-- 
Cheers,
-Mark

---

From: Joe Gregorio <[email-masked]>
Date: Wed, 14 Jul 2004 13:21:11 -0400

> *this* is an accessible alternative to *that*.

I could be wrong, but I thought there was movement towards
a content model that only allowed two types of content, either XML
or escaped HTML. 

Regardless I see no harm in removing something that is 
broken and waiting until later to decide on what to replace it 
with. It could even be replaced in the short term with an empty section
titled "Accessibility" and just filled with "TBD".

   -joe

---

From: Tim Bray <[email-masked]>
Date: Wed, 14 Jul 2004 10:43:27 -0700

On Jul 14, 2004, at 10:08 AM, Mark Pilgrim wrote:

> inaccessible to people with certain disabilities.

Ouch, it had somehow escaped my attention that this was an 
accessibility issue.  Mark is clearly correct that this Cannot Be 
Ignored.  On the other hand, I still think the current two levels of 
<atom:content> distinguished by the type= value feels like bad markup 
design and isn't clear enough what the real goal is.

MarkP is the guy who gets paid to think about accessibility, and thus 
the obvious candidate to write up a Pace for the right thing to do in 
Atom to support this properly and at a cost low enough that we can 
bully the vendors to do the right thing with some hope of success.  If 
he's prepared to argue that the current multipart/alternative is the 
best we can do, that's fine, but that argument has not so far been made 
on the grounds of accessibility.   Also, I think that the spec MUST 
have explicit normative content saying that if you are pushing 
non-textual content through, you SHOULD use said mechanism to provide 
accessible alternatives. -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Jul 2004 10:58:07 -0700

I'm confused. Mark says that the current design allows inaccessible 
content, and therefore we shouldn't get rid of the current design?

What am I missing here?

Also, I'm not sure that allowing inaccessible content (i.e., images) in 
Atom is the same as "baking discrimination into the core"; by that 
logic, discrimination is baked into HTML.

I very much agree that we should take positive steps to accommodate 
accessibility.

On Jul 14, 2004, at 10:43 AM, Tim Bray wrote:

> best we can do, that's fine, but that argument has not so far been 
> made on the grounds of accessibility.   Also, I think that the spec 
> MUST have explicit normative content saying that if you are pushing

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 20:04:35 +0200

On Wed, 14 Jul 2004 13:08:24 -0400, Mark Pilgrim <[email-masked]> wrote:

> -1 on nuking it without an alternative proposal in place.

Okay. I'm not sure if a good alternative proposal will surface anytime  
soon, though. And in the meantime, the current, and very complex mechanism  
remains as the standard. I'm not sure that's a good idea.

> that we have some mechanism for allowing publishers to include
> accessible alternatives in the same feed, in a way that makes it
> clear that *this* is an accessible alternative to *that*.

The element does not have to be introduced to Atom with this pace, but it  
is at least a pace that proposes Atom to adopt Dublin Core's <relation>[1]  
element. The pace's name is PaceIssuedAndRelation[2] and is created as a  
solution for re-issuance of entries.

The good thing about <relation> is that it solves a lot of Atom's  
problems, all in one element, all from one standard. If we adopt it, Atom  
would be able to do:

   - Versioning and re-issuance (IsVersionOf and HasVersion)

   - Fragmentation (IsPartOf and HasPart)

     Could be used for linking individual parts of an entry to the
     entry itself, or individual entries to the «greater whole» the
     entries constitute.

   - Make assertions about alternate formats of a resource (IsFormatOf
     and HasFormat)

     Could be used as a replacement for the ambiguous 'rel="alternate"'
     link construct, to more explicitly state what what you're linking
     to.

     This could imho be a good alternative to the current 'multipart/
     alternative' mechanism.

   - Threading (References and IsReferencedBy)

   - Translations (IsBasedOn and IsBasisFor)

   - Dependancy-checks on resources (Requires and IsRequiredBy)

     I don't know a good use case for this, but one could imagine that
     an entry doesn't «work» without some external part of it not being
     downloaded or viewed with the entry.

I think this element solves so many problems that we should seriously  
consider to adopt it.

> If you thought I was passionate about certain issues before, you ain't

I appreciate your passion in regard to accessibility, because you're the  
number one watchdog on inaccessible features and mechanisms. This is a  
quality we need, beccause I don't think there are a lot of people all too  
concerned with this, and if there are, they haven't got the experience  
needed to catch stuff like this alternative mechanism, for instance.

____
[1] <url: http://dublincore.org/documents/relation-element/>
[2] <url: http://intertwingly.net/wiki/pie/PaceIssuedAndRelation>

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 14 Jul 2004 14:05:30 -0400

> content, and therefore we shouldn't get rid of the current design?

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.

Note: publishers frequently publish inaccessible content without
accessible alternatives.  That is an advocacy problem, not a
specification problem.  What Tim proposed would create a specification
problem.

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.

-- 
Cheers,
-Mark

---

From: Robert Sayre <[email-masked]>
Date: Wed, 14 Jul 2004 14:30:25 -0400

>replacing the syntax with something better, but we can't simply remove

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: Dan Brickley <[email-masked]>
Date: Wed, 14 Jul 2004 14:40:22 -0400

* Mark Nottingham <[email-masked]> [2004-07-14 10:58-0700]
> logic, discrimination is baked into HTML.

A lot of folk are very interested in RSS/Atom feeds for sharing of
digital images, typically photo blogs. Often from mobile phones, eg.
here's one I contribute to with some friends:
http://moblog.nicecupoftea.org/

While JPGs may themselves be inaccessible, it is perfectly possible to 
package them with metadata which carries more info about their content
to search engines, directories, non-visual browsers and to visually
impaired users. 

For example, Matt Biddulph has done some nice work using RDF, Wordnet,
FOAF and Dublin Core.
http://www.hackdiary.com/archives/000020.html
http://www.hackdiary.com/archives/000034.html
http://picdiary.com/

This shows that search tools built over namespace-extended feeds can 
make the items described by those feeds more accessible. Eg. searching
over the people in the images, 
http://www.picdiary.com/cgi-bin/findmbox.pl?mbox=mailto:[email-masked]
or by the things in the images, 
http://www.picdiary.com/cgi-bin/search.pl?word=hotel (not working
currently, ahem). 

Rather than try to stop folk including (by value or reference; principle
is the same) audio and image content in their feeds, I believe our
energies would be better spent encouraging them to associate extra info
with those items. I'm well aware that people don't like to take the time
to add metadata, but also that folk do like their photos to be findable
again and that extension namespaces can play a role in supporting that. 

cheers,

Dan

ps. http://www.kanzaki.com/works/2004/imgdsc/0106.html
http://kanzaki.com/courier/xs/works/2003/imagedesc/photo.rdf.html
http://kanzaki.com/test/exif2rdf?xsl=on&ul=/works/2003/imagedesc/031114_2152.jpg
for more examples, the latter using XSLT and exploiting auto-embedded 
GPS info.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 14 Jul 2004 22:56:02 +0200

On Wed, 14 Jul 2004 13:21:11 -0400, Joe Gregorio <[email-masked]>  
wrote:

> Regardless I see no harm in removing something that is broken and waiting
> until later to decide on what to replace it with. It could even be
> replaced in the short term with an empty section titled "Accessibility"
> and just filled with "TBD".

+1. I think the current model is broken, and that it shouldn't be in the  
specification. The longer it stays there, the longer it will take to get  
rid of the potential implementations of it.

---

From: Ken MacLeod <[email-masked]>
Date: 14 Jul 2004 16:35:40 -0500

Dan Brickley <[email-masked]> writes:

> Rather than try to stop folk including (by value or reference;
> principle is the same) audio and image content in their feeds, I
> believe our energies would be better spent encouraging them to
> associate extra info with those items. I'm well aware that people
> don't like to take the time to add metadata, but also that folk do
> like their photos to be findable again and that extension namespaces
> can play a role in supporting that.

PaceSimpleContentType was driven in part by the multipart/alternative
issue, as well as the "binary upload" and "what is an Internet Media
Type entity represented as XML Characters" issues.

That Pace lightly addresses the accessibility issue: put the "best
representation" in content/@src, put alternate representations of the
content in (proposing here) content-alternate/@src.

  (End of main reply, clarifications follow.)

Note, the current spec still contains text that says "multiple
<content> elements are allowed", but provides *no* processing rules
for determining "best" representations among them, and document order
(by other processing rules in Atom) is not considered significant(+1).
PaceSimpleContentType dissallows multiple <content> elements rather
than re-specify MIME precedence rules.

Note that MIME multipart/alternative processing rules ranks the
alternatives, whereas PaceSimpleContentType only indicates "best" and
"alternates", leaving the client to select among the alternates based
on media type.

It is possible in theory that a URI referenced content/@src resource
may be content-type negotiable, but I doubt anyone would seriously
consider that an option for both standard content negotiation issues
as well as publisher implementation reasons.

It is possible in theory that a URI referenced content/@src resource
may itself be a multipart/alternative MIME media type, but "Put
simply, the Web doesn't know about compound objects."
(PaceNonEntryResources, et al)

PaceSimpleContentType chooses to explicitly label (type) each content
use rather than overload semantics from MIME:

  * content is the "best representation"
  * content/@src is content-by-reference
  * 0+ content-alternate elements are alternates
  * 0 or 1 content-source is the "source representation" (for editing
    purposes)

Note, 'content-alternate' has the same relation type as the
'alternate', but denotes an alternate of the content or content
reference, not the entry itself.

  -- Ken

---

From: Matt May <[email-masked]>
Date: Thu, 15 Jul 2004 08:35:31 -0700

> titled "Accessibility" and just filled with "TBD".

Ack. In my experience, most specs that go this way end up reading 
"Accessibility: TBD" through 0.9, after which all spec-related decisions 
have been decided without adequate consideration for accessibility. I 
recommend marking up accessibility issues now, rather than expecting 
that they'll pop up later.

W3C/WAI published a document called the XML Accessibility Guidelines. A 
better title would be So You've Decided to Create an Accessible 
Language. It gives a list of accessibility-related needs, and the 
rationale for each. It's highly-recommended reading for language developers.

http://www.w3.org/TR/xag

If people find it useful, I can also arrange some sort of interaction 
between Atom and the WAI Protocols and Formats WG, whose job it is to 
review specs like Atom for accessibility issues. That can take the form 
of getting someone to join us on our weekly telecon, or just pointing 
them to threads where questions arise.

-
m

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 15 Jul 2004 12:31:38 -0400

> that they'll pop up later.

We have Mark. That won't happen. Trust me.

   -joe

---

From: Sam Ruby <[email-masked]>
Date: Thu, 15 Jul 2004 13:12:22 -0400

> We have Mark. That won't happen. Trust me.

But didn't Mark recommend that we keep the current wording until there 
is an alternative proposal in place[1]?

"We have Mark, but we don't listen to him".

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg06991.html

---

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

> logic, discrimination is baked into HTML.
Which is no reason to continue with a weak / inaccessible design IMHO.

> I very much agree that we should take positive steps to accommodate 

+1
Lessons from docbook perhaps?
<mediaobject>
  <mediaOne ..
  <alt 1 ..
  <alt 2 ..
</mediaobject>

I.e. present as a group with alternatives in other format.

regards DaveP  

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

---

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

> again and that extension namespaces can play a role in supporting that. 

Nice bonus with this approach is that the author can add the personal 
remark, name the people in the image,
tell us what kit was used for it etc.

---

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

Dave Pawson <[email-masked]> writes:

> > like their photos to be findable again and that extension
> > namespaces can play a role in supporting that.
> 
> Nice bonus with this approach is that the author can add the
> personal remark, name the people in the image, tell us what kit was
> used for it etc.

Note that there is some overlap here between "metadata about a
resource" and "what is an entry".  An entry is a resource that is
formally published (the thing that is added to the front page or feed)
whereas metadata is attached to resources.

The overlap occurs because often one can be used alongside or in place
of the other.  For example, one might upload a photo with its
metadata, and then later come back an make an entry with that photo as
the body content.  Naturally, the properties for the entry would
likely come mostly from the photo's metadata, but there could be lots
of other user supplied content for the entry that isn't metadata for
the photo.

PaceExtendedResourcePosting uses a technique similar to the earlier
PaceDontSyndicate proposal, of providing an alternate usage of <entry>
for attaching metadata to a resource, but without making that resource
a published entry in its own right.  My preference over that would be
to use the atom:resource element from PaceResource (make clear that
this is a resource metadata container resource, not an entry
resource).  My preference over *that* would be to use WebDAV
properties :-).

  -- Ken

---

From: Janne Jalkanen <[email-masked]>
Date: Fri, 16 Jul 2004 14:31:31 +0300

>resource).  My preference over *that* would be to use WebDAV
WebDAV is cool, too, but note that it's also restricted by the same 
problems on the MIDP platform - and you'd have to do PROPPATCH and 
PROPFIND support in addition to DELETE and PUT :-)

PaceExtendedResourcePosting has a couple of good sides:
* Suits well with the current Atom structure (uses same syntax, Resource 
Metadata is exactly an EditURI)
* Is not as complex as a full WebDAV class 1 system
* Does not require the server side to implement a DAV server as well
* Simple to implement
* Does not require extending HTTP

But on the other hand
* It duplicates some of the DAV functionality
* Is not as powerful.

I have really no opinion on using <resource> instead of <entry>.

/Janne