> They could "display" the summary and provide a "Download the entry
> content" link. If they know how to "display" the content, then they
> can generate HTML code (an xhtml:object) with fallback to the summary:
> <object data="where/is/stored/the/entry/content" type="image/svg+xml">
> <p>If you see this message, it generally means your browser does
> not know how to display content of type "image/svg+xml". However, the
> entry publisher has provided this summary for you to read:</p>
> <p>...entry's summary...</p>
> </object>
> <p><a href="where/is/stored/the/entry/content"
> hreftype="image/svg+xml">Download the entry content...</a></p>
Good idea.
> Alternate "formats" should be linked to using <link rel="alternate"
> href="..." />
Agreed, but it requires the supports from aggregators since special treatment
is needed when atom:content/@src is present.
Also, there can only be 1 alt. line.
atom:entry elements MUST NOT contain more than one atom:link
element with a rel attribute value of "alternate" that has the
same combination of type and hreflang attribute values.
Franklin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Broyer
Sent: Wednesday, November 22, 2006 23:55
To: Atom-Syntax
Subject: Re: The "src" attribute of atom:content
2006/11/22, Tse Shing Chi (Franklin/Whale):
>
> There is an unexpected reply located in
> http://www.imc.org/atom-protocol/mail-archive/msg07722.html.
Oops, sorry!
(double-checked, this time, I answer to atom-syntax ;-) )
> Quote:
>
> <atom:content type="image/svg+xml">...</atom:content>
> I don't know how to display such a content within a widget, however
> I know there is some program in the "registry" (Windows Registry,
> Freedesktop's shared MIME database, OS X configuration, etc.) which is
> able to open it; so I whot the summary (if any) and provide "Open
> with..." and "Save as..." buttons. I couldn't do that with an
> xhtml:object embeded in an <atom:content type="xhtml"/> (or eventually
> type="html").
>
> It is almost what I want aggregators to do actually. However, web-based
> aggregators may have difficulties in handling it.
They could "display" the summary and provide a "Download the entry
content" link. If they know how to "display" the content, then they
can generate HTML code (an xhtml:object) with fallback to the summary:
<object data="where/is/stored/the/entry/content" type="image/svg+xml">
<p>If you see this message, it generally means your browser does
not know how to display content of type "image/svg+xml". However, the
entry publisher has provided this summary for you to read:</p>
<p>...entry's summary...</p>
</object>
<p><a href="where/is/stored/the/entry/content"
hreftype="image/svg+xml">Download the entry content...</a></p>
> Currently, the way to provide alternate format or text... seems to be the
> followings.
I personnaly have no problem with a summary acting as an alternate
text (to display if the content can't be): hey, there's a valid reason
why summary must be provided if the content is out-of-line or
base64-encoded ;-)
Alternate "formats" should be linked to using <link rel="alternate"
href="..." />
> Anyway, no one can ensure that aggregators will display the summary
> when they are [NOT] able to show the content.
Right, but I hope and expect those aggregators to either be updated or
tend to disappear (because people will switch to "better"
aggregators).
--
Thomas Broyer
