Abstract
This proposal introduces the atom:resource element, and removes the current semantics of the type="multipart/alternative" attribute of <content>, with the aim of providing a simpler and more consistent way of dealing with multipart posts, compound posts, and resources that are not Atom entries.
This, along with the PaceObjectModule, PaceDontSyndicate, and PaceNonEntryResources proposals, all present alternative methods for enabling the creation and editing of entries which logically contain non-textual objects such as pictures and video.
Status
Open
Rationale
The following rationale is mostly copied from PaceObjectModule
This proposal attempts to solve the same problems identified in PaceDontSyndicate with a different solution. See that Pace's Rationale section for discussion on the Atom Syndication Format 0.3 pre-draft's problematic notion of compound entries:
"Put simply, the Web doesn't know about compound objects."
Other syndication formats and APIs offer methods of dealing with resources that are not entries, either alone, or together with an entry. Atom can provide similar functionality with a new element-- atom:resource.
By adopting the element, Atom can support the posting of graphics and other multimedia objects (alone or together with an entry), references to external media objects (as with RSS2 Enclosures), and the inclusion of related media content inline if necessary.
Comparison
Compared to PaceDontSyndicate, this proposal is distinguished in that it doesn't try to reuse atom:entry for both top-level entries and non-textual components. This (like PaceObjectModule) is motivated by objections from Sam Ruby and others that components and component entries are logically distinguished and can be expected to have different content models and so on.
Compared to PaceObjectModule, this proposal is distinguished in that it doesn't try to reuse xhtml:object, but invents a new Atom element to do the job. This is motivated by observations that xhtml:object comes with a lot of apparatus that may be useless or even counter-productive for Atom, and that keeping core elements of a language in the same namespace has some value.
Also, probably revealing that this is an orthogonal issue, this proposal restricts an atom:entry to having only one atom:content element.
Proposal
Replace the body of 4.13.10 with: "The 'atom:content' element is a Content construct that conveys the content of the entry. An atom:entry element MAY contain one atom:content elements"
Add section 4.14 as follows:
4.14 "atom:resource" Element
The atom:resource element describes a Resource (in the Web sense, identifieable by a URI) which is part of the publication but which will not appear as a separate top-level item, nor in the syndication feed.
The attributes and elements which are allowed for atom:resource as the same as those allowed for atom:entry.
Examples
Post an entry along with an image
Request
(forgive the lack of root element, that's a separate issue)
POST /t/atom/weblog/blog_id=1 HTTP/1.1 Host: www.typepad.com X-WSSE: my credentials <?xml version="1.0" encoding='utf-8'?> <entry xmlns="http://purl.org/atom/ns#"> <title>Trip to the Lake</title> <issued>2003-09-08T03:32:51Z</issued> <content type="application/xhtml+xml" mode="xml"><div xmlns="http://www.w3.org/1999/xhtml"><img src="#Image_16" /> Here is a picture of me at the lake.</div></content> </entry> <resource> <title>Joe Fishing</title> <issued>2003-09-08T03:32:51Z</issued> <summary>Joe fishing in the red rowboat. He is looking away from the camera, with a scenic backdrop of lake and forest.</summary> <content type="image/jpg" mode="base64"> ... a whole lot of base64 ... </content> </resource>
Response
TBD
Impacts
The structure of an atom:entry is simplified, a new child element of feed is added, and the design patterns for posting compound entries change.