Given a separate technique for creating and managing arbitrary content types (PaceSimpleResourcePosting, PaceNonEntryResources), the opportunity arises to vastly simplify the remaining inline content cases to only XML text (markup and/or characters) and escaped HTML markup, and content-by-reference for specifying full body content using an arbitrary Internet media type. This proposal removes the @type attribute of "Content Constructs" and removes the 'base64' mode (replaced by content-by-reference). The 'escaped' mode is replaced by 'escaped-html', as that is the only backwards compatible use for escaped markup.

PaceContentSrc is an alternative that provides a "src" attribute for content-by-reference for all Content constructs, where this Pace only allows a "src" attribute for full body content and alternates.



Author: KenMacLeod

Revised: 29-Jul-2004, 15-Jul-2004, 8-Jun-2004



The "unbounded openness" of allowing arbitrary MIME content types in Content Constructs has always been strongly debated. One of the principle use cases for this unbounded openness was the ability to create and manage "complex" and multipart entries. Recently, several proposals have come forward (PaceSimpleResourcePosting, PaceNonEntryResources) to handle complex, multipart entries in a more robust and direct manner. Therefore, the content models of the <name>, <title>, <tagline>, <copyright>, <info>, <summary>, and <content> can be reduced to just the common cases of escaped HTML or XML text (markup and/or characters).

Further, the Content construct of the format has never been thoroughly specified. It does not specify what the interpretation, or profile, of an arbitrary media type resource should be, particularly the definition of a "resource" or "payload", whether the mode attribute is base64 or not. The Content construct, and the atom:content element in particular, never specified the informative elements originally found in content (internal wiki link currently broken).

This proposal allows content-by-reference only for the atom:content element ("src" and "type"), and alternatives for that content using a new atom:content-alternate element.

One other use case for multipart/alternative content or allowing multiple <content> elements is multiple language content. multipart/alternative was only ever specced for <content> and not other fields, which tends to make this case not applicable. This proposal relies on the user creating unique entries and using xml:lang for multiple languages.

Why is <content-alternate> required when alternate textual content could be inline in the <content> element?


(1) Replace section [WWW]3.1 Content Constructs with the following:

(2) Replace section 4.13.10 "atom:content" Element with the following:

(3) Add a new section 4.13.XX "atom:content-alternate" Element with the following:

(4) In each Content construct Atom element, specify whether it uses "inline", "paragraph", or "block" content.

(5) Add new section, Content Profiles, and subsections as below:


This proposal deprecates the @type attribute (it can be ignored by processors).

The @mode value of "base64" is dropped. The extent of the usage of this mode is unknown. The TypePad Atom implementation uses base64 entries for uploading photos, which this Pace presumes will be superceded by PaceSimpleResourcePosting / PaceNonEntryResources.

The @mode value of "escaped" is changed to "escaped-html" as a cue to users. During transition, consumers receiving "escaped" should treat it as "escaped-html".

Non-text content that previously may have been found in <content) (extent unknown) is moved to a <link> construct.


The current specification has several dimensions of extensibility (content type, mode of encoding, partial content, XML namespaces, multipart content) that contribute to its complexity.

This proposal reduces the extensibility to two areas:


Changes from 15-Jul-2004:

Changes from [WWW]8-Jun-2004 (3-Jul-2004) ([WWW]diff):

Changes from [WWW]original version ([WWW]diff):