I don't think the content element is being used as intended here.

With type="text", it's a container for the actual feed entry or a direct link to it.

With type="html", the entry can contain meaningful html entities so the feed can dispense with all the fuss associated with encoding and validation

With type-"xhtml", the content being included should be valid xhtml wrapped in a div tag. The record is pretty clear that div is intended only to have elements as children (even if the xhtml recommendation can't specifically disallow mixed content).

The examples here really ought to be of type="text", or encased in xhtml markup that is being used for some practical reason, eg, something like:

  <content type="xhtml">
    <div xmlns="http://www.w3.org/1999/xhtml">
      <p>Classic dystopian novel by English author George Orwell (see also <em>Shooting an Elephant</em></p>.
    </div>
  </content>

Moreover, these examples are not what Atom expects in content but instead in summary.

Clearly Atom is adaptable to this purpose, even if it was cut precisely to the needs of blogging syndication. As OPDS needs to adapt it, still the intentions of the Atom authors ought to be observed, IMO.

So I also have problems with how link is being implemented.

With blogging, the Atom feed entry ought to include either a content child — containing the full blog post or a link to it (and the link relationship identified as 'alternate') — or a summary child whose content is an extract, abstract or short summary of one of the three types above.

If OPDS is a catalog of books, then there's a mismatch between the blog model and the catalog model. The content in the catalog is material about a book, and the feed therefore ought to have the full material in content or a summary of it. A link child of content should take the feed's consumer to that "full material."

So maybe the catalog copy shouldn't be likened to blog posts.

Then content could contain a link to the epub, and the catalog description would go into summary. Of course, the full descriptions in the catalog might be too long to use as intended in this type of feed.

In that case, just create a new type of relationship link, as was done in the examples for cover image and thumbnail, that describes whether this longer content is a synopsis, review or just longer description.

So, to stay with the extended Atom, I would expect the example to look more like this:

<entry>
    <title>1984</title>
    <summary>
      Classic dystopian novel by English author George Orwell.
    </summary>
    <id>urn:billybobsbooks:1166</id>
    <id>urn:lcc:PR6029.R8 N49</id>
    <author>
      <name>Orwell, George</name>
      <uri>http://orlabs.oclc.org/identities/lccn-n79-58639</uri>
      <uri>http://authorities.loc.gov/cgi-bin/Pwebrecon.cgi?AuthRecID=1424083&v2=1&HC=1&SEQ=20090504144121&PID=_wO7DdLLzVchRiLF8uicoha89</uri>
    </author>
    <updated>2008-09-12T00:44:20+00:00</updated>
    <content src="http://www.billybobsbooks.com/book/1984.epub" type="application/epub+zip" />
    <link rel="http://opds-spec.org/opds-cover-image-thumbnail" type="image/png"
      href="http://www.billybobsbooks.com/book/1984-thumb.png" title="cover thumbnail"/>
    <link rel="http://opds-spec.org/opds-cover-image" type="image/png"
      href="http://www.billybobsbooks.com/book/1984.png" title="cover image"/>
    <link rel="http://opds-spec.org/opds-author-image" type="image/png"
      href="http://upload.wikimedia.org/wikipedia/commons/2/23/GeoreOrwell.jpg" title="author photo"/>
    <link rel="related" href="http://catalog.loc.gov/cgi-bin/Pwebrecon.cgi?v1=11&ti=1,11&SC=Title&SA=Nineteen%20eighty-four&PID=ofT1R1v0gMNdf-CWVtQwFgMGb&SEQ=20090504144908&SID=2" title="Disambiguation page for this book" />
</entry>

Very interesting point rsperberg and I agree with what you've said. A simple summary though won't be enough, and we should also discuss how to describe categories (atom:category ?), the language (dc:language ?) and other various atrributes of a book that are currently mashed together in the content.

Agree with rsperberg as well. You may also be interested to see how ORE serialized its compound digital object descriptions (Aggregations) in Atom: http://www.openarchives.org/ore/1.0/atom