Subject: Re: The "src" attribute of atom:content

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 19 Nov 2006 17:15:29 +0100

* Tse Shing Chi (Franklin/Whale) <[email-masked]> [2006-11-19 16:05]:
> Unfortunately, numbers of feed aggregators will not follow the
> src attribute probably due to security reasons.

atom:content/@src is indeed not well supported. Many aggregators
aren’t even aware of the attribute and don’t do even as much as
showing a link to the external content. This is broken; please
file a bug against the aggregator in question.

> However, it is actually an abuse of atom:summary because the
> "atom:summary" element is a Text construct that conveys a short
> summary, abstract, or excerpt of an entry.
 
Agreed.

> More unfortunately, feed aggregators will not consider this
> entry is linking to http://www.example.org/ even though the
> content is external.

This is correct and by design (though implementation correctness
here is probably often by accident; see above).

> The followings are my thoughts.
> 
> 1. When the "src" attribute of atom:content is present, it
> includes the meaning of having an alternate link to the same
> URI inside "src".
> 
> 2. atom:content SHOULD NOT be empty. I think that atom:content
> is something like xhtml:object. Alternate contents should be
> put inside the element.

We could discuss whether these ideas would have been worthwhile.
However, this is moot, as the spec is done and cannot be changed.
Since these suggestions are incompatible with RFC 4287, they
cannot be recommended as best practices either. Sorry. :-(

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

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 00:54:18 +0800

Why can't change the specification? It is currently a proposed standard only.

I still think that providing alternate content is very important... at least... add an "alt" attribute to atom:content as if xhtml:img...

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of A. Pagaltzis
Sent: Monday, November 20, 2006 00:15
To: [email-masked]
Subject: Re: The "src" attribute of atom:content

 
Agreed.

Regards,

---

From: James M Snell <[email-masked]>
Date: Sun, 19 Nov 2006 09:19:41 -0800

The spec can be changed, it's just not a great idea to do so until we
get a critical mass of issues that can't seem to be adequately worked
around.

You can accomplish what you're trying to do by throwing in an alternate
link, using the summary element and dropping the content.

<entry>
  <title>Example Title</title>
  <id>http://www.example.org/</id>
  <summary>A simple explanation of quantum entaglement</summary>
  <link type="text/html" src="http://www.example.org/" />
  <published>2006-11-19T13:05:00Z</published>
  <updated>2006-11-19T13:05:00Z</updated>
</entry>

However, you should do as Aristotle suggests and file a bug report with
any aggregator that does not support the content/@src attribute.

- James

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 01:53:18 +0800

The spec. mentioned, "Atom Processors MAY choose to ignore remote content". However, there is no instructions or guidelines for aggregators to follow about what they should do when they choose not to load the external content.

> link, using the summary element and dropping the content.

Yes, I can. But what is the use of atom:content/@src then? The src attribute can be removed from the spec if it is the case.

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Monday, November 20, 2006 01:20
To: Tse Shing Chi (Franklin/Whale)
Cc: [email-masked]
Subject: Re: The "src" attribute of atom:content

<entry>

- James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 20 Nov 2006 06:33:16 +0100

* Tse Shing Chi (Franklin/Whale) <[email-masked]> [2006-11-19 19:10]:
> But what is the use of atom:content/@src then? The src
> attribute can be removed from the spec if it is the case.

External content is useful for binary formats; inlining huge
base64-encoded binary blobs would be silly. Keep in mind that
Atom is intended as a general envelope format with more use cases
than just weblog feeds, even if that is all it is currently used
for.

For now, weblog publishing platforms tend to treat Atom as
completely interchangable with RSS 2.0 in terms of features. So
in practice, aggregators do not yet really support features of
Atom that go beyond RSS 2.0. I believe this will change in time,
and the APP will probably be a catalyst there, but for the time
being, on the open web, Atom is just a better RSS. Fancier uses
will tend to run into lack of support.

Regards,

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 15:46:54 +0800

In fact, I do hope that content/@src is useful. I asked that question because I really wonder whether the alternate link + summary "workaround" can replace content/@src.

However, content/@src is NOT clearly defined at the moment, specially what aggregators should do.

When aggregators do not understand the remote content in (a). Why should they do? There is no alternate link provided, should a link to the external content be shown? The specification mentioned, "Atom Processors MAY choose to ignore remote content", but it does not mean that a Atom Processors should ignore whole entry.

The author of the feed knows the issue, but there is no way for him to solve the problem. The specification of Atom does not give him a chance to provide alternate format of content.

The condition may be better in (b), where there is a summary. The author assumed that aggregators will show the summary when the content is not loaded. However, this action in undefined in any standard and not all aggregators follow. On the other hand, the author is actually abusing the summary element. Even though aggregators really show the summary, should a link to the external content be shown? There is no alternate link provide.

There is an alternate link, a summary and a remote content in (c). But does it mean that everything works fine? And, where is the difference between (c) and (d) finally? Does it mean that using the content/@src in an Atom feed is useless?

I hope the examples can clarify what I am concerning about. The problem of content/@src is not only caused by aggregators, but also the poor definition of atom:content in the specification.

Franklin

Reference:

(a) <entry>
      <title>Example Title</title>
      <id>http://www.example.org/example.pdf</id>
      <content type="application/pdf" src="http://www.example.org/example.pdf" />
      <published>2006-11-20T07:28:00Z</published>
      <updated>2006-11-20T17:28:00Z</updated>
    </entry>

(b) <entry>
      <title>Example Title</title>
      <id>http://www.example.org/example.pdf</id>
      <summary><!-- some alternate text --></summary>
      <content type="application/pdf" src="http://www.example.org/example.pdf" />
      <published>2006-11-20T07:28:00Z</published>
      <updated>2006-11-20T17:28:00Z</updated>
    </entry>

(c) <entry>
      <title>Example Title</title>
      <id>http://www.example.org/example.pdf</id>
      <link rel="alternate" type="application/pdf" href="http://www.example.org/example.pdf" />
      <summary><!-- some alternate text --></summary>
      <content type="application/pdf" src="http://www.example.org/example.pdf" />
      <published>2006-11-20T07:28:00Z</published>
      <updated>2006-11-20T17:28:00Z</updated>
    </entry>

(d) <entry>
      <title>Example Title</title>
      <id>http://www.example.org/example.pdf</id>
      <link rel="alternate" type="application/pdf" href="http://www.example.org/example.pdf" />
      <summary><!-- some alternate text --></summary>
      <published>2006-11-20T07:28:00Z</published>
      <updated>2006-11-20T17:28:00Z</updated>
    </entry>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of A. Pagaltzis
Sent: Monday, November 20, 2006 13:33
To: [email-masked]
Subject: Re: The "src" attribute of atom:content

Regards,

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 20 Nov 2006 08:02:06 +0000

> However, content/@src is NOT clearly defined at the moment, specially what aggregators should do.

I'm not sure you've read Aristotle correctly. Aggregators are only one
of the target of Atom. The format is not focused solely on blog
publishing, it's much larger than that.

Therefore Atom may sound like lacking of clarity in some aspects but
this is because you read it as if the specification had been written for
one purpose only.

Your question should instead be brought up to the aggregator authors
attention so that some kind of best practice can be decided and implemented.

Not everything has to belong to the specification.

- Sylvain

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 16:26:24 +0800

> publishing, it's much larger than that.

I do think in what purpose of using atom:content/@src, alternate content in a different format is still necessary. NO Atom processors can understand all the media types in the world. 

> attention so that some kind of best practice can be decided and implemented.

Actually, all aggregators which support Atom are written based on the specification. It is not possible to ask ALL aggregators to follow the same mechanism unless or until it is specified. I still see the need to define the elements some mechanisms in the specification more clearly.

You may read my mail that you have replied again. I am asking numbers of questions about what authors and the aggregators can do. There are no answers found at the moment.

Franklin

-----Original Message-----
From: Sylvain Hellegouarch [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 16:02
To: Tse Shing Chi (Franklin/Whale)
Cc: [email-masked]
Subject: Re: The "src" attribute of atom:content

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Nov 2006 00:41:30 -0800

Tse Shing Chi (Franklin/Whale) wrote:
>[snip]
> I do think in what purpose of using atom:content/@src, alternate content in a 
> different format is still necessary. NO Atom processors can understand
all the
> media types in the world. 
> 

They don't have to understand the media type.  They merely have to
understand how to make that data available.  Atom processors can easily
dispatch the media to an appropriate application.

- James

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 16:50:05 +0800

> Atom processors can easily dispatch the media to an appropriate application.

Yes, some of them can. But a number of processors cannot do so, especially the web-based processors. As a result, a fallback mechanism is very necessary when they do not understand the remote content or they cannot dispatch the media to an appropriate application.

=========================

By the way, James, I found an Atom feed written by you testing the atom:content/@src.

http://www.snellspace.com/public/contentsummary.xml

You used <summary>If you're seeing this, your feed reader is doing a good thing. It doesn't understand the content so it is showing the text summary instead.</summary>. Actually it is the alternate text instead of the "summary".

On the other hand, this mechanism is undefined in the specification or in any related standards.

Franklin

-----Original Message-----
From: James M Snell [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 16:42
To: Tse Shing Chi (Franklin/Whale)
Cc: [email-masked]
Subject: Re: The "src" attribute of atom:content

all the

- James

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 20 Nov 2006 08:52:10 +0000

> I do think in what purpose of using atom:content/@src, alternate content in a different format is still necessary. NO Atom processors can understand all the media types in the world. 

But Atom processors don't have to understand any media types.
I can understand why applications built on top of Atom processors might
need a fallback position but not atom processors.

In any case if an application chooses not to follow the remote content
@src then it's up to that application to provide its own fallback.

- Sylvain

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 17:01:41 +0800

> @src then it's up to that application to provide its own fallback.

That's the problem. Since there is no defined fallback mechanism, the actual mechanism varies from application to application. Authors of an Atom feeds cannot expect feed readers will do, and they are not given a chance to provide alternate content in a different format.

Franklin

-----Original Message-----
From: Sylvain Hellegouarch [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 16:52
To: Tse Shing Chi (Franklin/Whale)
Cc: [email-masked]
Subject: Re: The "src" attribute of atom:content

- Sylvain

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 17:56:43 +0800

**This mail is to correct the last mail**

> @src then it's up to that application to provide its own fallback.

That's the problem. Since there is no defined fallback mechanism, the actual mechanism varies from application to application. Authors of Atom feeds cannot expect what feed readers will do, and they are not given a chance to provide alternate content in a different format.

Corrections:
1. deleted "an" before "Atom feeds"
2. added "what "before " feed readers will do" to complete the idea

Franklin

-----Original Message-----
From: Sylvain Hellegouarch [mailto:[email-masked]] 
Sent: Monday, November 20, 2006 16:52
To: Tse Shing Chi (Franklin/Whale)
Cc: [email-masked]
Subject: Re: The "src" attribute of atom:content

- Sylvain

---

From: Antone Roundy <[email-masked]>
Date: Mon, 20 Nov 2006 08:59:45 -0600

On Nov 19, 2006, at 11:53 AM, Tse Shing Chi ((Franklin/Whale)) wrote:
> The spec. mentioned, "Atom Processors MAY choose to ignore remote  
> content". However, there is no instructions or guidelines for  
> aggregators to follow about what they should do when they choose  
> not to load the external content.
That was a warning to feed producers that if they choose to use  
remote content, consumers might not see it.  There are no guidelines  
for what aggregators should do because:

1) we have no prior experience upon which to base our recommendations  
for a best practice in that case.

2) we didn't want to place the burden of any particular processing  
requirements on Atom processor authors in cases where producers have  
chosen to do things that are more complex than what's needed in most  
cases.

So the lack of instructions for how to handle such cases was  
intentional.  Over time, a best practice or best practices will  
emerge from actual experience in the market.   Perhaps some future  
specification will specify what to do, and maybe it will continue to  
be left up to the consuming application--which might be best if  
remote content remains an edge case.

> That's the problem. Since there is no defined fallback mechanism,  
> the actual mechanism varies from application to application.  
> Authors of Atom feeds cannot expect what feed readers will do, and  
> they are not given a chance to provide alternate content in a  
> different format.
Yep, that's why we warned them that remote content might get ignored.

Note that the Atom spec says:

    o  atom:entry elements MUST contain an atom:summary element in  
either
       of the following cases:
       *  the atom:entry contains an atom:content that has a "src"
          attribute (and is thus empty).

So some of your examples are invalid--they MUST contain atom:summary.

So here are the real questions that I can think of:

1) If there is only one representation of the content (the one  
pointed to by atom:content/@src), should there be an atom:link 
[@src="alternate"] pointing to it too?
2) If there is no atom:link[@src="alternate"], should atom:content/ 
@src should be used in in it's place?
3) If there is an atom:link[@src="alternate"] with a different type  
from atom:content/@type, should atom:content/@src be presented as  
another alternative?

If #2 is adopted as a best practice (...and is followed!), #1 would  
be entirely unnecessary.  Semantically, #1 is a little off anyway,  
because it's not an "alternative" representation, it's THE  
representation.

I think #3 shlu.d be left entirely up to the consuming application,  
because what's appropriate in some cases will not be appropriate in  
others.  It's essentially the same question as whether multiple  
atom:link[@src="alternate"] with different types will all be  
presented, or whether just one will be chosen.

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Mon, 20 Nov 2006 23:56:34 +0800

Thanks for reminding me that atom:entry elements MUST contain an atom:summary element when the atom:entry contains an atom:content that has a "src"attribute (and is thus empty).

However, summary is different with alternate text... In some cases, providing summary can be difficult.

Agreed.

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Tue, 21 Nov 2006 01:03:09 +0800

I know that atom:summary can carry the three pre-defined types only. 

Actually, a problem is still not solved, what should Atom processors do when they do not understand the content in an entry like (B)?

On the other hand, atom:content/@src can be replaced by xhtml:object like (A), and there is a good fallback mechanism defined in the HTML/XHTML Specification. Can it prove that atom:content/@src is not necessary?

Remark: Content in (B) is copied from http://www.w3.org/Icons/valid-svg11-v.svg.

- Reference -

A:
	<entry>
		<title>Example Test</title>
		<id>http://www.w3.org/Icons/valid-svg11-v.svg</id>
		<content type="xhtml">
			<div xmlns="http://www.w3.org/1999/xhtml">
				<object type="image/svg+xml" data="http://www.w3.org/Icons/valid-svg11-v.svg">
				  <!-- alternate text -->
				</object>
			</div>
		</content>
		<published>2006-11-20T11:50:00Z</published>
		<updated>2006-11-20T11:50:00Z</updated>
	</entry>

B:
	<entry>
		<title>Example Test</title>
		<id>http://www.w3.org/Icons/valid-svg11-v.svg</id>
		<content type="image/svg+xml">
			<svg xmlns='http://www.w3.org/2000/svg' xml:space='preserve' version='1.1' overflow='visible' xmlns:xlink='http://www.w3.org/1999/xlink' viewBox='0 0 88 31'>
				<g shape-rendering='geometricPrecision' text-rendering='geometricPrecision' image-rendering='optimizeQuality'>
					<g id='Background'>
					</g>
					<g id='Guides'>
					</g>
					<g id='Foreground'>
						<g>
							<polygon points='0,0 88,0 88,31 0,31 0,0   ' fill='none'/>
							<path d='M44,15.5' fill='none'/>
						</g>
						<g>
							<polygon points='0,0 83,0 83,31 0,31 0,0   ' fill='#FFCC66'/>
							<path d='M41.5,15.5' fill='#FFCC66'/>
						</g>
						<g>
							<polygon points='0.365,0 36.809,0 36.809,31 0.365,31 0.365,0   ' fill='#FFFFFF'/>
							<path d='M18.587,15.5' fill='#FFFFFF'/>
						</g>
						<g>
							<polygon points='4.692,2.291 44.697,2.291 44.697,26.898 4.692,26.898 4.692,2.291   ' fill='none'/>
							<path d='M24.695,14.594' fill='none'/>
						</g>
						<g>
							<g>
								<defs>
									<polygon points='0,30 83,30 83,31 0,31 0,30     ' id='XMLID_973_'/>
								</defs>
								<use xlink:href='#XMLID_973_' fill='#504D4C'/>
								<clipPath id='XMLID_999_'>
									<use xlink:href='#XMLID_973_'/>
								</clipPath>
								<g clip-path='url(#XMLID_999_)'>
									<g>
										<polygon points='0,0 88,0 88,31 0,31 0,0      ' fill='none'/>
										<path d='M44,15.5' fill='none'/>
									</g>
									<g>
										<polygon points='0,0 83,0 83,31 0,31 0,0      ' fill='#4E4B3F'/>
										<path d='M41.5,15.5' fill='#4E4B3F'/>
									</g>
									<g>
										<polygon points='0.365,0 36.809,0 36.809,31 0.365,31 0.365,0      ' fill='#4F4F4F'/>
										<path d='M18.587,15.5' fill='#4F4F4F'/>
									</g>
								</g>
							</g>
						</g>
						<g>
							<g>
								<defs>
									<polygon points='82,0 83,0 83,31 82,31 82,0     ' id='XMLID_975_'/>
								</defs>
								<use xlink:href='#XMLID_975_' fill='#504D4C'/>
								<clipPath id='XMLID_1000_'>
									<use xlink:href='#XMLID_975_'/>
								</clipPath>
								<g clip-path='url(#XMLID_1000_)'>
									<g>
										<polygon points='0,0 88,0 88,31 0,31 0,0      ' fill='none'/>
										<path d='M44,15.5' fill='none'/>
									</g>
									<g>
										<polygon points='0,0 83,0 83,31 0,31 0,0      ' fill='#4E4B3F'/>
										<path d='M41.5,15.5' fill='#4E4B3F'/>
									</g>
									<g>
										<g>
											<defs>
												<polygon points='0,30 83,30 83,31 0,31 0,30        ' id='XMLID_977_'/>
											</defs>
											<use xlink:href='#XMLID_977_' fill='#191919'/>
											<clipPath id='XMLID_1001_'>
												<use xlink:href='#XMLID_977_'/>
											</clipPath>
											<g clip-path='url(#XMLID_1001_)'>
												<g>
													<polygon points='0,0 88,0 88,31 0,31 0,0         ' fill='none'/>
													<path d='M44,15.5' fill='none'/>
												</g>
												<g>
													<polygon points='0,0 83,0 83,31 0,31 0,0         ' fill='#191917'/>
													<path d='M41.5,15.5' fill='#191917'/>
												</g>
												<g>
													<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0         ' fill='#191919'/>
													<path d='M18.587,15.5' fill='#191919'/>
												</g>
											</g>
										</g>
									</g>
								</g>
							</g>
						</g>
						<g>
							<polygon points='0,0 1,0 1,31 0,31 0,0   ' fill='#CCCCCC'/>
							<path d='M0.5,15.5' fill='#CCCCCC'/>
						</g>
						<g>
							<g>
								<defs>
									<polygon points='2.16,29.005 82.16,29.005 82.16,30.005 2.16,30.005 2.16,29.005     ' id='XMLID_979_'/>
								</defs>
								<use xlink:href='#XMLID_979_' fill='#9E9C9C'/>
								<clipPath id='XMLID_1002_'>
									<use xlink:href='#XMLID_979_'/>
								</clipPath>
								<g clip-path='url(#XMLID_1002_)'>
									<g>
										<polygon points='0,0 88,0 88,31 0,31 0,0      ' fill='none'/>
										<path d='M44,15.5' fill='none'/>
									</g>
									<g>
										<polygon points='0,0 83,0 83,31 0,31 0,0      ' fill='#B39F67'/>
										<path d='M41.5,15.5' fill='#B39F67'/>
									</g>
									<g>
										<polygon points='0.365,0 36.809,0 36.809,31 0.365,31 0.365,0      ' fill='#B5B5B5'/>
										<path d='M18.587,15.5' fill='#B5B5B5'/>
									</g>
									<g>
										<g>
											<defs>
												<polygon points='0,30 83,30 83,31 0,31 0,30        ' id='XMLID_981_'/>
											</defs>
											<use xlink:href='#XMLID_981_' fill='#383838'/>
											<clipPath id='XMLID_1003_'>
												<use xlink:href='#XMLID_981_'/>
											</clipPath>
											<g clip-path='url(#XMLID_1003_)'>
												<g>
													<polygon points='0,0 88,0 88,31 0,31 0,0         ' fill='none'/>
													<path d='M44,15.5' fill='none'/>
												</g>
												<g>
													<polygon points='0,0 83,0 83,31 0,31 0,0         ' fill='#383530'/>
													<path d='M41.5,15.5' fill='#383530'/>
												</g>
												<g>
													<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0         ' fill='#383838'/>
													<path d='M18.587,15.5' fill='#383838'/>
												</g>
											</g>
										</g>
									</g>
									<g>
										<g>
											<defs>
												<polygon points='82,0 83,0 83,31 82,31 82,0        ' id='XMLID_983_'/>
											</defs>
											<use xlink:href='#XMLID_983_' fill='#383838'/>
											<clipPath id='XMLID_1004_'>
												<use xlink:href='#XMLID_983_'/>
											</clipPath>
											<g clip-path='url(#XMLID_1004_)'>
												<g>
													<polygon points='0,0 88,0 88,31 0,31 0,0         ' fill='none'/>
													<path d='M44,15.5' fill='none'/>
												</g>
												<g>
													<polygon points='0,0 83,0 83,31 0,31 0,0         ' fill='#383530'/>
													<path d='M41.5,15.5' fill='#383530'/>
												</g>
												<g>
													<g>
														<defs>
															<polygon points='0,30 83,30 83,31 0,31 0,30           ' id='XMLID_985_'/>
														</defs>
														<use xlink:href='#XMLID_985_' fill='#131313'/>
														<clipPath id='XMLID_1005_'>
															<use xlink:href='#XMLID_985_'/>
														</clipPath>
														<g clip-path='url(#XMLID_1005_)'>
															<g>
																<polygon points='0,0 88,0 88,31 0,31 0,0            ' fill='none'/>
																<path d='M44,15.5' fill='none'/>
															</g>
															<g>
																<polygon points='0,0 83,0 83,31 0,31 0,0            ' fill='#131313'/>
																<path d='M41.5,15.5' fill='#131313'/>
															</g>
															<g>
																<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0            ' fill='#131313'/>
																<path d='M18.587,15.5' fill='#131313'/>
															</g>
														</g>
													</g>
												</g>
											</g>
										</g>
									</g>
								</g>
							</g>
						</g>
						<g>
							<g>
								<defs>
									<polygon points='80.806,1 81.806,1 81.806,31 80.806,31 80.806,1     ' id='XMLID_987_'/>
								</defs>
								<use xlink:href='#XMLID_987_' fill='#9E9C9C'/>
								<clipPath id='XMLID_1006_'>
									<use xlink:href='#XMLID_987_'/>
								</clipPath>
								<g clip-path='url(#XMLID_1006_)'>
									<g>
										<polygon points='0,0 88,0 88,31 0,31 0,0      ' fill='none'/>
										<path d='M44,15.5' fill='none'/>
									</g>
									<g>
										<polygon points='0,0 83,0 83,31 0,31 0,0      ' fill='#B39F67'/>
										<path d='M41.5,15.5' fill='#B39F67'/>
									</g>
									<g>
										<g>
											<defs>
												<polygon points='0,30 83,30 83,31 0,31 0,30        ' id='XMLID_989_'/>
											</defs>
											<use xlink:href='#XMLID_989_' fill='#383838'/>
											<clipPath id='XMLID_1007_'>
												<use xlink:href='#XMLID_989_'/>
											</clipPath>
											<g clip-path='url(#XMLID_1007_)'>
												<g>
													<polygon points='0,0 88,0 88,31 0,31 0,0         ' fill='none'/>
													<path d='M44,15.5' fill='none'/>
												</g>
												<g>
													<polygon points='0,0 83,0 83,31 0,31 0,0         ' fill='#383530'/>
													<path d='M41.5,15.5' fill='#383530'/>
												</g>
												<g>
													<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0         ' fill='#383838'/>
													<path d='M18.587,15.5' fill='#383838'/>
												</g>
											</g>
										</g>
									</g>
									<g>
										<g>
											<defs>
												<polygon points='2.16,29.005 82.16,29.005 82.16,30.005 2.16,30.005 2.16,29.005        ' id='XMLID_991_'/>
											</defs>
											<use xlink:href='#XMLID_991_' fill='#818181'/>
											<clipPath id='XMLID_1008_'>
												<use xlink:href='#XMLID_991_'/>
											</clipPath>
											<g clip-path='url(#XMLID_1008_)'>
												<g>
													<polygon points='0,0 88,0 88,31 0,31 0,0         ' fill='none'/>
													<path d='M44,15.5' fill='none'/>
												</g>
												<g>
													<polygon points='0,0 83,0 83,31 0,31 0,0         ' fill='#807659'/>
													<path d='M41.5,15.5' fill='#807659'/>
												</g>
												<g>
													<polygon points='0.365,0 36.809,0 36.809,31 0.365,31 0.365,0         ' fill='#818181'/>
													<path d='M18.587,15.5' fill='#818181'/>
												</g>
												<g>
													<g>
														<defs>
															<polygon points='0,30 83,30 83,31 0,31 0,30           ' id='XMLID_993_'/>
														</defs>
														<use xlink:href='#XMLID_993_' fill='#272727'/>
														<clipPath id='XMLID_1009_'>
															<use xlink:href='#XMLID_993_'/>
														</clipPath>
														<g clip-path='url(#XMLID_1009_)'>
															<g>
																<polygon points='0,0 88,0 88,31 0,31 0,0            ' fill='none'/>
																<path d='M44,15.5' fill='none'/>
															</g>
															<g>
																<polygon points='0,0 83,0 83,31 0,31 0,0            ' fill='#272623'/>
																<path d='M41.5,15.5' fill='#272623'/>
															</g>
															<g>
																<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0            ' fill='#272727'/>
																<path d='M18.587,15.5' fill='#272727'/>
															</g>
														</g>
													</g>
												</g>
												<g>
													<g>
														<defs>
															<polygon points='82,0 83,0 83,31 82,31 82,0           ' id='XMLID_995_'/>
														</defs>
														<use xlink:href='#XMLID_995_' fill='#272727'/>
														<clipPath id='XMLID_1010_'>
															<use xlink:href='#XMLID_995_'/>
														</clipPath>
														<g clip-path='url(#XMLID_1010_)'>
															<g>
																<polygon points='0,0 88,0 88,31 0,31 0,0            ' fill='none'/>
																<path d='M44,15.5' fill='none'/>
															</g>
															<g>
																<polygon points='0,0 83,0 83,31 0,31 0,0            ' fill='#272623'/>
																<path d='M41.5,15.5' fill='#272623'/>
															</g>
															<g>
																<g>
																	<defs>
																		<polygon points='0,30 83,30 83,31 0,31 0,30              ' id='XMLID_997_'/>
																	</defs>
																	<use xlink:href='#XMLID_997_' fill='#101010'/>
																	<clipPath id='XMLID_1011_'>
																		<use xlink:href='#XMLID_997_'/>
																	</clipPath>
																	<g clip-path='url(#XMLID_1011_)'>
																		<g>
																			<polygon points='0,0 88,0 88,31 0,31 0,0               ' fill='none'/>
																			<path d='M44,15.5' fill='none'/>
																		</g>
																		<g>
																			<polygon points='0,0 83,0 83,31 0,31 0,0               ' fill='#101010'/>
																			<path d='M41.5,15.5' fill='#101010'/>
																		</g>
																		<g>
																			<polygon points='0.366,0 36.809,0 36.809,31 0.366,31 0.366,0               ' fill='#101010'/>
																			<path d='M18.587,15.5' fill='#101010'/>
																		</g>
																	</g>
																</g>
															</g>
														</g>
													</g>
												</g>
											</g>
										</g>
									</g>
								</g>
							</g>
						</g>
						<g>
							<polygon points='0,0 83,0 83,1 0,1 0,0   ' fill='#CCCCCC'/>
							<path d='M41.5,0.5' fill='#CCCCCC'/>
						</g>
						<g>
							<polyline fill-rule='evenodd' stroke='#990000' points='    68.273,18.845 74.291,24.348 86.001,12.637   ' clip-rule='evenodd' stroke-miterlimit='3.8637' stroke-width='4.8117' fill='none'/>
						</g>
						<g>
							<g>
								<path d='M33.077,7.038l0.334,2.034l-1.185,2.266c0,0-0.455-0.961-1.21-1.494c-0.636-0.448-1.051-0.545-1.699-0.412     c-0.833,0.171-1.777,1.167-2.189,2.395c-0.493,1.469-0.498,2.179-0.515,2.832c-0.028,1.047,0.137,1.666,0.137,1.666     s-0.719-1.331-0.712-3.279c0.005-1.391,0.223-2.652,0.867-3.896c0.566-1.095,1.407-1.751,2.154-1.828     c0.772-0.08,1.383,0.292,1.854,0.695c0.495,0.422,0.996,1.347,0.996,1.347L33.077,7.038z'/>
								<path d='M33.222,18.547c0,0-0.523,0.936-0.85,1.296c-0.326,0.361-0.91,0.996-1.63,1.313c-0.721,0.317-1.099,0.377-1.811,0.309     c-0.712-0.068-1.373-0.48-1.605-0.652c-0.231-0.172-0.824-0.678-1.159-1.15c-0.335-0.472-0.858-1.416-0.858-1.416     s0.292,0.946,0.474,1.348c0.105,0.231,0.428,0.938,0.886,1.553c0.427,0.574,1.257,1.562,2.519,1.786     c1.262,0.223,2.128-0.344,2.343-0.481c0.214-0.137,0.667-0.516,0.953-0.822c0.299-0.32,0.582-0.728,0.738-0.972     c0.114-0.178,0.301-0.541,0.301-0.541L33.222,18.547z'/>
							</g>
							<g>
								<path d='M11.437,7.127l2.852,9.698l2.852-9.698h2.065l-4.721,15.933h-0.197l-2.95-9.875l-2.951,9.875H8.191     L3.47,7.127h2.065l2.853,9.698l1.928-6.531L9.372,7.127H11.437z' fill='#005A9C'/>
								<path d='M25.072,17.946c0,1.443-0.384,2.656-1.151,3.64c-0.767,0.983-1.761,1.475-2.98,1.475     c-0.918,0-1.718-0.292-2.4-0.875c-0.682-0.583-1.187-1.374-1.515-2.371l1.613-0.668c0.236,0.604,0.548,1.079,0.935,1.426     c0.387,0.348,0.843,0.521,1.367,0.521c0.551,0,1.016-0.308,1.397-0.924s0.571-1.357,0.571-2.223c0-0.958-0.203-1.698-0.61-2.223     c-0.473-0.616-1.214-0.925-2.223-0.925h-0.787v-0.944l2.754-4.761h-3.325l-0.925,1.574h-0.59V7.127h7.672v0.964l-2.911,5.016     c1.023,0.328,1.797,0.925,2.321,1.79C24.809,15.763,25.072,16.779,25.072,17.946z' fill='#005A9C'/>
							</g>
						</g>
						<g>
							<path clip-rule='evenodd' d='M45.064,6.052v1.543c-0.4-0.179-0.791-0.314-1.172-0.405    c-0.381-0.091-0.741-0.137-1.079-0.137c-0.449,0-0.781,0.062-0.996,0.186s-0.322,0.316-0.322,0.576    c0,0.195,0.071,0.348,0.215,0.459c0.146,0.107,0.41,0.2,0.791,0.278l0.801,0.161c0.811,0.163,1.387,0.41,1.729,0.742    s0.513,0.804,0.513,1.416c0,0.804-0.239,1.403-0.718,1.797c-0.476,0.391-1.203,0.586-2.183,0.586    c-0.462,0-0.926-0.044-1.392-0.132c-0.466-0.088-0.931-0.218-1.396-0.391v-1.587c0.465,0.248,0.915,0.435,1.348,0.562    c0.436,0.124,0.856,0.186,1.26,0.186c0.41,0,0.724-0.068,0.942-0.205c0.218-0.137,0.327-0.332,0.327-0.586    c0-0.228-0.075-0.404-0.225-0.527c-0.146-0.124-0.441-0.234-0.884-0.332l-0.728-0.161c-0.729-0.156-1.263-0.405-1.602-0.747    c-0.335-0.342-0.503-0.802-0.503-1.382c0-0.726,0.234-1.284,0.703-1.675s1.143-0.586,2.021-0.586c0.4,0,0.812,0.031,1.235,0.093    C44.173,5.842,44.611,5.931,45.064,6.052z' fill-rule='evenodd'/>
							<polygon points='46.423,5.822 48.313,5.822 50.247,11.203 52.176,5.822 54.065,5.822     51.365,13.112 49.124,13.112   ' clip-rule='evenodd' fill-rule='evenodd'/>
							<path clip-rule='evenodd' d='M61.685,12.57c-0.469,0.228-0.956,0.399-1.46,0.513s-1.025,0.171-1.563,0.171    c-1.214,0-2.176-0.338-2.886-1.016c-0.709-0.68-1.064-1.602-1.064-2.764c0-1.175,0.361-2.1,1.084-2.773s1.712-1.011,2.969-1.011    c0.485,0,0.949,0.046,1.392,0.137c0.446,0.091,0.866,0.227,1.26,0.405v1.509C61.009,7.51,60.604,7.337,60.2,7.224    c-0.4-0.114-0.802-0.171-1.206-0.171c-0.749,0-1.327,0.21-1.733,0.63c-0.404,0.417-0.605,1.014-0.605,1.792    c0,0.771,0.195,1.367,0.586,1.787s0.946,0.63,1.665,0.63c0.195,0,0.376-0.011,0.542-0.034c0.169-0.026,0.321-0.065,0.454-0.117    v-1.416h-1.147v-1.26h2.93V12.57z' fill-rule='evenodd'/>
						</g>
						<g>
							<polygon points='40.028,22.997 41.688,22.997 41.688,18.285 39.984,18.636     39.984,17.357 41.679,17.005 43.466,17.005 43.466,22.997 45.126,22.997 45.126,24.295 40.028,24.295   ' clip-rule='evenodd' fill-rule='evenodd'/>
							<rect fill-rule='evenodd' height='1.89' width='1.758' clip-rule='evenodd' y='22.406' x='46.435'/>
							<polygon points='50.786,22.997 52.446,22.997 52.446,18.285 50.742,18.636     50.742,17.357 52.436,17.005 54.223,17.005 54.223,22.997 55.883,22.997 55.883,24.295 50.786,24.295   ' clip-rule='evenodd' fill-rule='evenodd'/>
						</g>
					</g>
					<g id='Calque_1'>
					</g>
					<g id='Layer_1'>
					</g>
				</g>
			</svg>
		</content>
		<published>2006-11-20T11:50:00Z</published>
		<updated>2006-11-20T11:50:00Z</updated>
	</entry>

-----Original Message-----
From: Antone Roundy [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 00:50
To: Tse Shing Chi ((Franklin/Whale))
Subject: Re: The "src" attribute of atom:content

> providing summary can be difficult.

Sure, but the question is, where should the burden of handling that  
difficulty be placed?  The "text", "html" and "xhtml" types defined  
by Atom cover the vast majority of today's use cases for content in  
feeds.  In edge cases where the content is in a different format, the  
burden of providing a summary in one of the standard formats has been  
placed on the producer (vs. the alternatives of either requiring the  
consumer to be able to handle arbitrary data formats or leaving open  
the possibility of the consumer having access to neither the content  
nor a summary).

BTW, one point that I think has been missed thus far--atom:summary is  
a "Text construct", so it can only carry the three pre-defined types-- 
not things like application/xhtml+xml.  From the spec:

4.2.13.  The "atom:summary" Element

    The "atom:summary" element is a Text construct that conveys a short
    summary, abstract, or excerpt of an entry.

and:

3.1.1.  The "type" Attribute

    Text constructs MAY have a "type" attribute.  When present, the  
value
    MUST be one of "text", "html", or "xhtml".  If the "type" attribute
    is not provided, Atom Processors MUST behave as though it were
    present with a value of "text".  Unlike the atom:content element
    defined in Section 4.1.3, MIME media types [MIMEREG] MUST NOT be  
used
    as values for the "type" attribute on Text constructs.

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 20 Nov 2006 17:24:28 +0000

> Actually, a problem is still not solved, what should Atom processors do when they do not understand the content in an entry like (B)?

What do you mean by "understand"?

Every use case is listed in section 4.1.3.3 of RFC 4287. You still seem
to confuse processor and application consuming an Atom document.

> Remark: Content in (B) is copied from http://www.w3.org/Icons/valid-svg11-v.svg.

What is the improvement compare to atom:content/@src?

- Sylvain

---

From: James M Snell <[email-masked]>
Date: Mon, 20 Nov 2006 09:28:24 -0800

There is no "standard" or "recommended" way of handling [B].  User
agents will do whatever they choose to do and users will pick the UA
that does whatever is the most useful.

By way of example, Abdera will detect that the content is a "MEDIA" type
and will provide the mime type and xml content to the application
without attempting to do any further processing.

- James

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Tue, 21 Nov 2006 01:40:01 +0800

"Atom processors" here means some applications like aggregators. In fact, I really don't know how to call this type of applications.

"Understand" means that the application can parse and render the content. (Those applications can successfully show a SVG image here are 'understanding' the image/svg+xml media type.)

If xhtml:object can serve the function of atom:content/@src, then atom:content/@src is not necessary. The improvement is that xhtml:object has defined a fallback mechanism. When application cannot load the object, they should load the content inside the object. Refer to 13.3.1 of the HTML 4.01 Specification for details. (http://www.w3.org/TR/html401/struct/objects.html)

Franklin

-----Original Message-----
From: Sylvain Hellegouarch [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 01:24
To: Tse Shing Chi (Franklin/Whale)
Cc: 'Antone Roundy'; [email-masked]
Subject: Re: The "src" attribute of atom:content

- Sylvain

---

From: Eric Scheid <[email-masked]>
Date: Tue, 21 Nov 2006 11:57:04 +1100

On 21/11/06 4:03 AM, "Tse Shing Chi (Franklin/Whale)"
<[email-masked]> wrote:

> Actually, a problem is still not solved, what should Atom processors do when
> they do not understand the content in an entry like (B)?
> 
> On the other hand, atom:content/@src can be replaced by xhtml:object like (A),
> and there is a good fallback mechanism defined in the HTML/XHTML
> Specification. Can it prove that atom:content/@src is not necessary?

1) Content@src does facilitate reference to content which cannot be
represented within XML ... which includes any text containing control
characters, for example (e.g. ASCII art).

2) It also makes sense for content whose existence isn't normal to be
encapsulated, such as v-cards or v-events. I can easily imagine a feed of
v-events as the content.

3) Using link@rel='alternate' instead of content@src loses the facility to
say "*this* is the real thing, the others are alternative formats (which may
have lost something in translation)".

4) One can't also just stuff the v-event into an enclosure instead, because
how then do you indicate which is the actual content object, and any other
enclosures (including additional v-event objects).

e.

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Tue, 21 Nov 2006 10:38:47 +0800

Should a "charset" attribute be added? The remote content's encoding may not be the same as the feed's.

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Scheid
Sent: Tuesday, November 21, 2006 08:57
To: Atom Syntax
Subject: Re: The "src" attribute of atom:content

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 21 Nov 2006 17:48:29 +1100

> be the same as the feed's.

It could only be advisory in nature, and it wouldn't be particularly useful
(if at all) for selective dispatching (unlike @type on atom:content and
atom:link) ... so why bother?

e.

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Tue, 21 Nov 2006 17:58:44 +0800

In fact, I was just considering something like these: http://www.w3.org/TR/xhtml2/mod-embedding.html#adef_embedding_encoding and http://www.w3.org/TR/html401/struct/links.html#adef-charset.

It may be "charset" or "encoding".

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Scheid
Sent: Tuesday, November 21, 2006 14:48
To: Atom Syntax
Subject: Re: The "src" attribute of atom:content

e.

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 21 Nov 2006 21:06:50 +0100

* Tse Shing Chi (Franklin/Whale) <[email-masked]> [2006-11-20 11:15]:
> That's the problem. Since there is no defined fallback
> mechanism, the actual mechanism varies from application to
> application. Authors of Atom feeds cannot expect what feed
> readers will do, and they are not given a chance to provide
> alternate content in a different format.

I agree, after all the discussion, that this an aspect of Atom
that could have been better. I doubt anyone forsaw any need for
this at the time.

For the time being, you’ll have to make do with using
atom:summary as alternative text.

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 21 Nov 2006 21:10:57 +0100

* James M Snell <[email-masked]> [2006-11-19 18:35]:
> The spec can be changed, it's just not a great idea to do so
> until we get a critical mass of issues that can't seem to be
> adequately worked around.

Is anyone keeping a Possible Errata document or some such?
I recall several other discussions in the time since Atom was
submitted for approval where possibly legitimate issues were
raised, which ended inconclusively. Has anyone kept track?

Regards,

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Wed, 22 Nov 2006 22:02:28 +0800

There is an unexpected reply located in http://www.imc.org/atom-protocol/mail-archive/msg07722.html.

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.

Currently, the way to provide alternate format or text... seems to be the followings.

For examples:

<summary type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
    <object type="image/svg+xml" data="http://www.w3.org/Icons/valid-svg11-v.svg">
      <!-- alternate format, alternate text -->
      <img src="http://www.w3.org/Icons/valid-svg11.png" alt="Valid SVG 1.1" />
    </object>
  </div>
</summary>
<content type="image/svg+xml" src="http://www.w3.org/Icons/valid-svg11-v.svg" />

<summary type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
    <object type="application/pdf" data="http://www.w3.org/TR/xhtml11/xhtml11.pdf">
      <!-- alternate format -->
      <object type="text/html" data="http://www.w3.org/TR/xhtml11/">
        <!-- alternate text -->
        <p>...</p>
      </object>
    </object>
  </div>
</summary>
<content type="application/pdf" src="http://www.w3.org/TR/xhtml11/xhtml11.pdf" />

Anyway, no one can ensure that aggregators will display the summary when they are able to show the content. Also, I would like to repeat again, my examples are not the correct use of summary.

If you have any comment, please reply to [email-masked]

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of A. Pagaltzis
Sent: Wednesday, November 22, 2006 04:07
To: [email-masked]
Subject: Re: The "src" attribute of atom:content

Regards,

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Wed, 22 Nov 2006 22:07:43 +0800

Correction:

"when they are NOT able to show the content"

-----Original Message-----
From: Tse Shing Chi (Franklin/Whale) [mailto:[email-masked]] 
Sent: Wednesday, November 22, 2006 22:02
To: [email-masked]
Subject: RE: The "src" attribute of atom:content

Quote:

For examples:

<summary type="xhtml">

<summary type="xhtml">

Franklin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of A. Pagaltzis
Sent: Wednesday, November 22, 2006 04:07
To: [email-masked]
Subject: Re: The "src" attribute of atom:content

Regards,

---

From: "Thomas Broyer" <[email-masked]>
Date: Wed, 22 Nov 2006 16:54:30 +0100

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 ;-) )

> 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

---

From: "Tse Shing Chi \(Franklin/Whale\)" <[email-masked]>
Date: Thu, 23 Nov 2006 01:03:43 +0800

> hreftype="image/svg+xml">Download the entry content...</a></p>

Good idea.

> Alternate "formats" should be linked to using <link rel="alternate"

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-masked] [mailto:[email-masked]] On Behalf Of Thomas Broyer
Sent: Wednesday, November 22, 2006 23:55
To: Atom-Syntax
Subject: Re: The "src" attribute of atom:content

Oops, sorry!

-- 
Thomas Broyer

---

From: Brendan Taylor <[email-masked]>
Date: Thu, 23 Nov 2006 11:31:01 -0700

> Is anyone keeping a Possible Errata document or some such?

There's one[1] on the wiki. I've updated it with this issue (fallback
content) and the other one I can remember (extension attributes on
atom:link).

1: <http://www.intertwingly.net/wiki/pie/RFC4287Errata>