Abstract
It appears that PaceContentAsTextOrHtml, PaceContentSrc, PaceNukeMultipart, PaceSimpleContentType are all related, and that discussion on the WG up to September 3 suggests consensus is achievable on the related issues.
Status
Open
Rationale
The number and type of values for the @type attribute, the kludginess of the @mode attribute, and the handling of accessibility issues are all strongly related. This proposal gives us a single <atom:content> element, provides a simple set of rules for dispatching on @type values without excessively limiting the repertoire of types, and provides a good accessibility baseline.
Proposal
Replace section 3.1 with a new section:
3.1 Text Constructs
A Text Construct contains human readable text, usually in fairly small quantitities.
Text Constructs MAY have a "type" attribute, whose value indicates the media type of the content. When present, the value MUST be one of "text/plain", "text/html", or "application/xhtml+xml". If this attribute is not present, software MUST behave as though it were present with a value of "text/plain".
If the value is "text/html" or "text/plain" the content MUST be markup-free text (the same as what XML 1.0 calls "#PCDATA"), containing no child elements. Thus, if the value is "text/html", the HTML markup must be escaped; for example, "<br>" as "<br>". If the value is "application/xhtml+xml" the content MUST be well-formed.
If the value is "text/html" or "application/xhtml", the content SHOULD be HTML or XHTML text and markup that could validly appear directly within an HTML or XHTML "body" element. Receiving software MAY use this HTML or XHTML markup to aid in displaying the content.
---
Change the definitions of "atom:title", "atom:tagline", "atom:copyright", "atom:info", and "atom:summary" to define them as "Text Constructs" rather than "Content Constructs"
---
Add the following paragraph to 5.9 "atom:summary" Element
atom:entry elements MUST contain an atom:summary element in any of the following cases:
-
the atom:entry element contains no atom:content element.
-
the atom:entry contains an atom:content which has an "src" attribute (and is thus empty).
-
the atom:entry contains content which is encoded in base64; i.e. the "type" attribute of atom:content is present with a value which does not begin with "text/" or end with "+xml".
---
Replace 5.10 "atom:content" element as follows
5.10 "atom:content" Element
The "atom:content" element either contains or links to the content of the entry. atom:entry elements MUST contain zero or one atom:content elements.
atom:content MAY have a "type" attribute, whose value gives the internet media type of the content. Any registered internet media type is allowed except for those which begin with "multipart/". If the "type" attribute is absent, software MUST behave as though it were present with a value of "text/html".
atom:content MAY have a "src" attribute, whose value MUST be a URI. If the "src" attribute is present, software MAY use to retrieve the content. If the "src" attribute is present, atom:content MUST be empty. If the "src" attribute is present, the "type" attribute's value is advisory; that is to say, upon derferencing the URI to retrieve the content, if the server providing that content also provides a media type, the server-provided media type is authoritative.
If the value of type begins with "text/" or ends with "+XML", the content SHOULD be local; that is to say, no "src" attribute should be provided.
Software MUST apply the following rules in succession in the order below to ascertain the method in which the content of atom:content is encoded.
-
If the value of "type" is "text/html", the content of atom:content MUST be markup-free text (the same as what XML 1.0 calls "#PCDATA"), containing no child elements, which SHOULD be suitable for handling by software that knows HTML. Thus, the HTML must be encoded; for example, "<br>" as "<br>".
-
If the value of "type" begins with "text/" the content of atom:content MUST be markup-free text (the same as what XML 1.0 calls "#PCDATA"), containing no child elements.
-
If the value of "type" ends with "+xml", the content of atom:content MUST be well-formed XML, which SHOULD be suitable for handling by software that knows the indicated media type.
-
For all other values of type, the content of atom:content MUST be a valid base64 encoding, which when decoded SHOULD be suitable for handling by software that knows the indicated media type.
If the value of "type" is "text/html" or "application/xhtml+xml", the content (however encoded) SHOULD be HTML or XHTML text and markup that could validly appear directly within an HTML or XHTML "body" element. Receiving software which displays such content SHOULD use this markup to aid in displaying it.
Example
<feed version="draft-ietf-atompub-format-01: do not deploy"
xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-01">
<head>
<title type="text/html">Example Feed</title>
<link rel="alternate" type="text/html"
href="http://example.org/index.atom"/>
<modified>2003-12-13T18:30:02Z</modified>
<author>
<name>John Doe</name>
</author>
</head>
<entry>
<title>How to use <style></title>
<id>tag:example.org,2003:3.2397</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary type="text/html">A lengthy discourse on do&rsquo;s and
don&rsquo;ts for the HTML &lt;style> element</summary>
<content src="http://example.com/htmlessons/style" />
</entry>
<entry>
<title>How to use <BLINK></title>
<id>tag:example.org,2003:3.2398</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary type="application/xhtml+xml">Don’t!</summary>
<!-- note no content -->
</entry>
<entry>
<title type="application/xhtml+xml">How to use <hr /></title>
<id>tag:example.org,2003:3.2399</id>
<updated>2003-12-13T18:30:02Z</updated>
<!-- no summary; OK because content is here -->
<content style="text/plain"><hr /> is a strictly graphical element
which draws a horizontal line. <hr />, <hr/>, and <hr></hr>
are all equivalent strictly speaking, but the first form is the most
common.</content>
</entry>
<entry>
<title>Friday cat-blogging!</title>
<id>tag:example.org,2003:3.2400</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Fluffy ripping a gerbil's liver out! Look at the vivid
reproduction of the many shades of red.</summary>
<content type="image/jpeg" src="http://example.com/pix/fluffy27.jpg" />
</entry>
<entry>
<title>Small Red Dot</title>
<id>tag:example.org,2003:3.2401</id>
<updated>2003-12-13T18:30:02Z</updated>
<summmary>One red pixel in a 5x5 grid.</summary>
<content type="image/gif">
R0lGODlhBQAFAJEAAAAAAP////8AAAAAACwAAAAABQAFAAACBYyPJslRADs=
</content>
</entry>
</feed>
Impacts
Notes
-
[AsbjornUlsberg, KenMacLeod] 3.1 Text Constructs should provide the ability for elements to constrain to a single inline value. So, "atom:title", "atom:tagline", "atom:copyright", "atom:info" would allow only inline, and "atom:summary" would allow block (which include inline).
-
[AsbjornUlsberg, KenMacLeod] xml:space's default value should be "preserve" when the attribute is absent. This means that parsers and intermediaries should preserve all the whitespace within Text Constructs. When presented (to a user, for example), the whitespace may be processed any way reasonable for the given presentation medium.
-
[AsbjornUlsberg, KenMacLeod] text/plain [RFC2046] has numerous processing implications that would need to be clearly specified. Instead, we should specify that text/plain is always normalized, and producers should use HTML or XHTML to provide line or paragraph-oriented text.
-
[AsbjornUlsberg, KenMacLeod] @type SHOULD be present when content is referenced with @src.
-
[AsbjornUlsberg, KenMacLeod] When @type is used authoritively, we must allow content type parameters. We can do that less obtrusively by inverting it and saying that for non-base64, only 'type/subtype' are allowed for content type.
