Subject: Is atom:content *the* place to put content?

From: Richard Salz <[email-masked]>
Date: Tue, 6 Jan 2009 18:01:41 -0500

Happy New Year.

I want to add content to an atom:entry, but it's intended for use by 
computers not humans. I know atom:content can hold arbitrary XML, but I'm 
not sure if I should use that or if I should put it as a direct child of 
the atom:entry element.

I don't like usurping the "human-readable" intent of atom:content. Also, 
since it's Language-Sensitive, I have a slight concern about someone 
translating machine field names and the like. There's a (slight) chance 
that the content could from different components, which is why I prefer 
inserting elements into atom:entry instead of "rewriting" atom:content.  I 
don't have any justficiation for that other than "gut feel" however.

I want to be able to associate a schema with the data (see 
http://www.ibm.com/developerworks/blogs/page/soma), and using atom:entry 
seems cleaner.  But it's a small matter to say the schema link relation is 
scoped to the atom:entry atomInlineOtherContent type.

So, what should I do?

        /r$

--
Visiting Member, IBM Academy
STSM, DataPower Chief Programmer
WebSphere DataPower SOA Appliances
http://www.ibm.com/software/integration/datapower/

---

From: Martin Atkins <[email-masked]>
Date: Tue, 06 Jan 2009 15:14:09 -0800

> scoped to the atom:entry atomInlineOtherContent type.

In practice, you don't want to put anything other than HTML in 
atom:content if you intend this feed to be consumed by general Atom 
processors and aggregators. Many aggregators (and feed re-publishers) 
will misbehave with anything other than <content type="html"> and 
escaped content.

You can add arbitrary XML elements as children of atom:entry, and use 
xml:lang to define what human language is within.

Of course, if you intend this feed to only ever be consumed by your own 
software it doesn't really matter what you do as long as your producer 
and your consumer agree.

If you are able to give more details about specifically what you are 
trying to do folks might be able to suggest a way to do it that does not 
involve extending Atom at all, at least at the XML level.

---

From: James M Snell <[email-masked]>
Date: Tue, 06 Jan 2009 16:19:54 -0800

One thing that needs to be kept in mind... and that feed reader 
developers need to make sure they're handling properly... is that Atom 
intentionally provides two locations for human readable content: 
atom:content and atom:summary.  If the atom:content element does not 
contain readily displayable content (like HTML), then the atom:summary 
element should be used to provide some kind of displayable approximation.

- James

Martin Atkins wrote:
>> computers not humans. I know atom:content can hold arbitrary XML, but 
>> I'm not sure if I should use that or if I should put it as a direct 
>> child of the atom:entry element.
>>
>> I don't like usurping the "human-readable" intent of atom:content. 
>> Also, since it's Language-Sensitive, I have a slight concern about 
>> someone translating machine field names and the like. There's a 
>> (slight) chance that the content could from different components, 
>> which is why I prefer inserting elements into atom:entry instead of 
>> "rewriting" atom:content.  I don't have any justficiation for that 
>> other than "gut feel" however.
>>
>> http://www.ibm.com/developerworks/blogs/page/soma), and using 
>> atom:entry seems cleaner.  But it's a small matter to say the schema 
>> link relation is scoped to the atom:entry atomInlineOtherContent type.
>>
>
> Of course, if you intend this feed to only ever be consumed by your 
> own software it doesn't really matter what you do as long as your 
> producer and your consumer agree.
>
> trying to do folks might be able to suggest a way to do it that does 
> not involve extending Atom at all, at least at the XML level.
>
>

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 7 Jan 2009 12:05:25 +0100

> I don't like usurping the "human-readable" intent of atom:content.

Atom makes no constraint that the content be human-readable. That
was in fact one of the goals differentiating it from RSS: the
ability to carry content other than plaintext or HTML.

If you want the feed to also be human-consumable, provide a
reasonable facsimile of the context in text or HTML form in the
summary.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "James Holderness" <[email-masked]>
Date: Wed, 7 Jan 2009 20:13:42 -0000

James Snell wrote:
> One thing that needs to be kept in mind... and that feed reader developers 
> need to make sure they're handling properly... is that Atom intentionally 
> provides two locations for human readable content: atom:content and 
> atom:summary.  If the atom:content element does not contain readily 
> displayable content (like HTML), then the atom:summary element should be 
> used to provide some kind of displayable approximation.

But feed producers also need to bare in mind that the summary element is not 
the place for alternate representations (in the sense of 
multipart/alternate). You don't put an XML document format in the content 
and then an alternate HTML version in the summary. Nor do you but a image 
format in the content an HTML img thumbnail in the summary (I'm looking at 
you, Picasa).

The summary should be a short, human-readable, text abstract or excerpt.

Regards
James

---

From: Tim Bray <[email-masked]>
Date: Thu, 08 Jan 2009 10:40:58 -0800

> I don't like usurping the "human-readable" intent of atom:content.

I don't think the spec, either explicitly or implicitly, says that  
atom:content ought necessarily to be human-readable.  It does give  
specific guidance on what to do when it's not (provide some guidance  
in atom:summary).  I suspect that mainstream consumer feed-readers are  
smart enough to simply bypass atom:content if it's in a format they  
don't understand.  So my instinct would be to use atom:content -Tim

---

From: Bill de hOra <[email-masked]>
Date: Thu, 08 Jan 2009 19:08:08 +0000

> reasonable facsimile of the context in text or HTML form in the

What Aristotle said. Formally speaking, atom:content isn't a Text 
construct and so doesn't imply its human readable intent.

Bill

---

From: "James Holderness" <[email-masked]>
Date: Thu, 8 Jan 2009 23:13:31 -0000

Tim Bray wrote:
> I suspect that mainstream consumer feed-readers are  smart enough to 
> simply bypass atom:content if it's in a format they  don't understand.

I guess it depends on your definition of mainstream. Google Reader? 
Bloglines? My Yahoo? As Martin said, there are still many feed-readers that 
don't deal very well with content that isn't HTML.

And it's not the sort of bug that's a high priority to fix since, by 
definition, it only applies to feeds whose content you can't view anyway. 
Not many users are going to be that excited about being able to subscribe to 
a summary of your content.

Bottom line: if you have content that can be rendered as HTML, and you want 
real people to subscribe to your feed, you'd be unwise to use anything other 
than HTML in the content element.

Regards
James