RE: A question regarding multiple content

["Jeremy Gray" <jeremy@xxxxxxxxxxxxx>]

I see all sorts of discussions of how multipart/alternative would be the
prior-art-respecting way to go for multiple content down the road, and I
agree that it would respect prior art.

However, and this is the FAR more important part, I see far too few
discussions as to whether or not multiple inline content of ANY form is
desirable for any justifiable reason, and the only poll I have seen on the
issue clearly shot down multiple inline content on that basis.

I still really don't understand how, given that this is supposed to be a
community effort, especially one that doesn't invent or adopt things that
are not clearly justified, that the multiple content crowd got their way in
the face of being defeated in a poll. Oh well. So much for the wikiocracy.

Jeremy

-----Original Message-----
From: owner-atom-syntax@xxxxxxxxxxxx [mailto:owner-atom-syntax@xxxxxxxxxxxx]
On Behalf Of Sjoerd Visscher
Sent: Friday, August 08, 2003 2:43 PM
To: atom-syntax@xxxxxxx
Subject: Re: A question regarding multiple content



Jeremy Gray wrote:

> For a while now I have noticed the vast majority (if not all) examples 
> of entry XML including (or at least acknowledging the allowed use of) 
> multiple content.
> 
> However, a long-standing poll on multiple content (located at
> http://www.intertwingly.net/wiki/pie/ContentDiscussion) shows multiple 
> content losing to what I'll call the "zero or one" crowd by a notable 
> margin (on percentage, obviously, not sheer numbers).

Yeah, I think this is why the 0.2 snapshot shows the multipart/alternative
example. This is a possible solution how to do multiple content versions
with one content element. With the added advantage of knowing the relation
between the multiple content elements, and being based on proir art
(e-mail).

Some discussion took place here: http://www.intertwingly.net/blog/1500.html
Ken McLeod noted that once people agree this is the best solution, multipart
mime-types could be "reserved for future use".

Because this was just after http://www.intertwingly.net/blog/1499.html,
where Tim Bray pledged for no inventions. We should keep remembering that
(it's hard, I know). Atom 1.0 should not contain "radical new capabilities".
It should however not close the door on inventions, the multipart mime-type
allows us to do exactly that. But it's not something we should be focusing
on now, certainly not in examples that outsiders will see as an introduction
to Atom.

--
Sjoerd Visscher
http://w3future.com/weblog/