Subject: Re: Comments on format-05

From: Eric Scheid <[email-masked]>
Date: Tue, 01 Feb 2005 11:15:46 +1100

On 1/2/05 6:02 AM, "Mark Nottingham" <[email-masked]> wrote:

> If the concern about multiple content is solely that it will result in
> more bandwidth use, I think it's misplaced; people who are concerned
> about bandwidth won't publish multiple representations inline; forcing
> them not to by legislation is misguided.

+1

---

From: Eric Scheid <[email-masked]>
Date: Tue, 01 Feb 2005 11:14:23 +1100

On 1/2/05 5:31 AM, "Antone Roundy" <[email-masked]> wrote:

> Another option would be to allow one <content> with inline content, and
> alternative content by reference, eg. (not being careful about getting
> language tags correct):

+1

---

From: Graham <[email-masked]>
Date: Tue, 1 Feb 2005 15:47:34 +0000

> them not to by legislation is misguided.

It's the implementation costs at the client. If you allow multiple 
content of the same mime-type, even minimal software has to have a 
significantly more complicated interface to allow users to choose which 
one to show, and a significantly more complex database to make it 
happen.

Big fat -1.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Feb 2005 10:02:49 -0800

Using XPath as a yardstick, what's so complex about this?

/atom:feed/atom:entry[1]/atom:content[@type='HTML'|@type='TEXT'][0]

I'm not even sure how I'd approach choosing between HTML and text in 
the current approach, where one is in atom:content and the other is 
referred to by atom:link; I'd need to use XSLT, I suspect.

If your software only wants to live in a world where entries have only 
one type of content, it's maybe a few lines of extra code to choose 
one, and no change to the database. Atom doesn't require you to persist 
all of the entry.

On Feb 1, 2005, at 7:47 AM, Graham wrote:

>> If the concern about multiple content is solely that it will result 
>> in more bandwidth use, I think it's misplaced; people who are 
>> concerned about bandwidth won't publish multiple representations 
>> inline; forcing them not to by legislation is misguided.
>
> significantly more complicated interface to allow users to choose 
> which one to show, and a significantly more complex database to make 
> it happen.
>
> Big fat -1.
>
> Graham

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

---

From: Robert Sayre <[email-masked]>
Date: Tue, 01 Feb 2005 13:17:33 -0500

Mark Nottingham wrote:

> one, and no change to the database. Atom doesn't require you to 
> persist all of the entry.

We dropped multiple content elements months ago, with good reason. Two 
of the more serious concerns were accessbility and the fact that nobody 
uses them in Atom 0.3. As I understand it, the only reason they were 
there originally was for uploading photos, an approach which is no 
longer necessary.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 1 Feb 2005 18:17:36 +0000

There's an awful lot more to an aggregator than the 3 lines that pull 
stuff out of XML. My problem is that users want to see the content in 
their preferred language, which means I have to provide some mechanism 
to choose, which may end up being the most complex part of a simple 
app. Additionally, think about search. Which content to do I look at? 
If I look at both or all languages, do I display the 2 or more versions 
of the same entry in the results? This is not easy to do with elegant 
GUI code and requires a much more complex object model.

And as I said, no one is going to use the functionality anyway.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 Feb 2005 10:56:00 -0800

On Feb 1, 2005, at 10:17 AM, Graham wrote:

> app.

I agree that varying representations in the feed by language isn't 
productive, when you can vary the whole feed by language. I haven't 
been arguing that we should allow variance by language.

To be clear, I'm less interested in allowing people to put multiple 
representations in the feed (although I think it should be possible; 
e.g., for archiving -- which we're chartered to enable) than I am in 
making sure people understand that it's possible to have more than one 
representation for a resource.

So, I'm not going to lie in the road to defend multiple content, but 
would ask for an adjustment in the language to clarify things;

From:

[[[
4.15  The "atom:content" Element

    The "atom:content" element either contains or links to the content of
    the entry.
]]]

to:

[[[
4.15  The "atom:content" Element

    The "atom:content" element conveys a representation of the entry's 
content, either
by containing it directly, or by linking to it. Other representations 
of the entry
may exist; see the atom:link element.
]]]

> And as I said, no one is going to use the functionality anyway.

Wow, that's a nifty trick. If you can tell me the outcome of the 
Superbowl next week, I'll cut you into the proceeds.

---

From: Tim Bray <[email-masked]>
Date: Tue, 01 Feb 2005 11:28:44 -0800

On Feb 1, 2005, at 10:17 AM, Robert Sayre wrote:

> of the more serious concerns were accessbility and the fact that 
> nobody uses them in Atom 0.3. As I understand it, the only reason they 
> were there originally was for uploading photos, an approach which is 
> no longer necessary.

No, it was there also as an accessibility measure, but the constraints 
on src= and the requirement for a summary in some cases do a better 
job. -Tim