Subject: PaceSimpleContentType and friends

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 17:04:59 -0700

I think it would be helpful for the authors of PaceSimpleContentType, 
PaceContentSrc, and PaceContentAsTextOrHtml to have a caucus and see if 
these three can be reduced to a single proposal.  If this is not 
possible, it would be very helpful for someone to post an analysis here 
of the areas of overlap and options and areas of disagreement. -Tim

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 08:06:10 -0400

> of the areas of overlap and options and areas of disagreement. -Tim

Key questions that need to be resolved, on an element by element basis:

(1) should we allow content-by-reference.

(2) should we allow non-textual content?

  = = =

Once these questions are resolved, there are some secondary questions, 
like how does one present alternatives to non-textual content for 
accessibility reasons, and how does one indicate the type of content?

My preference is that content-by-reference and non-textual content be 
allowed *only* on the content element.  If either is present, then a 
textual summary is required.

"image/jpeg" seems like a natual and evocative way to express "this 
content is a jpeg".  Ken MacLeod finds such usage to be "confusingly 
similar in appearance to Internet Media Types".

- Sam Ruby

---

From: [email-masked] (John Panzer)
Date: Tue, 31 Aug 2004 09:11:43 -0700

Sam Ruby wrote:

>> PaceContentSrc, and PaceContentAsTextOrHtml to have a caucus and see 
>> if these three can be reduced to a single proposal.  If this is not 
>> possible, it would be very helpful for someone to post an analysis 
>> here of the areas of overlap and options and areas of disagreement. -Tim
>
>
(Note: PaceContentSrc is purely about content indirection, and doesn't 
talk about the content types.  Maybe it would make sense to deal with 
PaceSimpleContentType + PaceContentAsTextOrHtml first?)

> (2) should we allow non-textual content?
For atom:content only:

I argue that we should allow non-textual content types direct 
atom:content data.  (We also allow non-textual content types as part of 
HTML content -- <img @src>, <object>,  etc. but that's not what's being 
discussed here.)

Use cases include a photoblog where each entry is a single photograph, 
with metadata; and entries which natively consist of non-textual content 
-- PDF, for example.

A downside is that aggregators may not be able to handle a particular 
content type, and so would presumably have to skip it or handle it the 
way browsers do today (asking if you have a program to view it, or if 
you want to download it).  On the other hand, this is what will happen 
anyway if you reference a content type in atom:content HTML that the 
aggregator, or its HTML widget, doesn't recognize (e.g., 
"image/foobar").  So this doesn't really introduce any problems that 
weren't already present.  Finally, if we don't provide a core way to do 
this, it'll be done in various private extensions.  So I argue this 
belongs in the core.

> (1) should we allow content-by-reference.
For non-textual atom:content, the alternative to content-by-reference is 
to base64 encode it and inline it.  The arguments against requiring this 
are:  33% overhead in size and down/up-load times; reduced ability to 
cache large binary objects via standard HTTP caching mechanisms; 
existing practice in HTML uses content-by-reference for the analagous 
case (<img @src>).

I argue for allowing content-by-reference in atom:content only, at least 
for non-textual content.

-John

---

From: Ken MacLeod <[email-masked]>
Date: 31 Aug 2004 11:47:07 -0500

> similar in appearance to Internet Media Types".

That statement is taken out of context, it doesn't apply to the
advisory media type of the thing at the other end of @src.

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 13:57:00 -0400

> advisory media type of the thing at the other end of @src.

I think it was correct in this context, but let's find out with a few 
examples:

The current form of html in Atom 0.3 is thus:

   <content type="text/html" mode="escaped">text</content>

With PaceSimpleContentType, this becomes:

   <content type="escaped-html">text</content>

With PaceContentAsTextOrHtml, this becomes:

   <content type="text/html">text</content>

If there is consensus that there needs to be a way to support a content 
which is a jpeg, what would the example look like if it were inlined as 
base64?

- Sam Ruby

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 31 Aug 2004 14:22:56 -0400

John Panzer wrote:
> A downside is that aggregators may not be able to handle a
> particular content type, and so would presumably have to skip it
> or handle it the  way browsers do today (asking if you have a
> program to view it, or if you want to download it).
	Feeds, entries, or XML formatted content itself could carry
references to XSL Templates that could be used to generate default
html/xhtml renderings. Also, the <link> element of an entry could be used to
point to an alternate representation that might be of a type more easily
handled by the aggregator..

		bob wyman

---

From: Robert Sayre <[email-masked]>
Date: Tue, 31 Aug 2004 20:24:51 -0400

> of the areas of overlap and options and areas of disagreement. -Tim

Areas of Overlap/Disagreement
------------------------------------------------

Content By Reference:
PaceSimpleContentType and PaceContentSrc provide nearly identical 
mechanisms. PaceContentAsTextOrHtml does not mention it, and so rules it 
out.

The "type" attribute:
PaceContentAsTextOrHtml-- allows text, text/html, or application/xhtml+xml
PaceSimpleContentType-- Posits that that MIME is inappropriate for 
describing the child content of an XML element. Allows it only when @src 
is also present. Uses @mode alone for inline content.
PaceContentSrc-- status quo. Doesn't mention that Atom 0.3 @mode would 
be meaningless for indirect content.

The "mode" attribute:
PaceContentSrc-- silent.
PaceSimpleContentType-- uses @mode to describe inline content.
PaceContentAsTextOrHtml-- removes @mode. uses @type to describe inline 
content. Does not allow base64 or content by reference.

Multiple content elements:
PaceContentAsTextOrHtml-- 1 <content> allowed.
PaceSimpleContentType-- 1 <content> allowed, but also allows any number 
of <content-alternate>.
PaceContentSrc-- silent.

Manifestion in various Atom elements:
PaceContentAsTextOrHtml-- everything is simple, so everything is simple.
PaceSimpleContentType-- allows content @src only in <content>.
PaceContentSrc-- allows content @src everywhere [spec bug? -RS]

base64:
PaceContentAsTextOrHtml-- removed.
PaceSimpleContentType-- removed.
PaceContentSrc-- Silent on inline, many use cases would go for @src instead.

any old XML inline:
PaceContentAsTextOrHtml-- removed.
PaceSimpleContentType-- provides a mode for this.
PaceContentSrc-- silent.

PaceNukeMultipart
------------------------------------------------
Assertion: No one needs or likes it, given the acceptance of 
PaceSimpleResourcePosting. The only objections concern the continued 
presence of accessible content in Atom.

The Mailing List
------------------------------------------------
People have spoken up in favor of base64 and any XML content.
Assertion: base64 and 'any old XML' are useful for <content>, but not 
other elements.

Possible Way Forward
------------------------------------------------
* <content> is unique, don't make it the same construct as the other 
elements

* allow only one <content>, use links for alternate representations and 
"relateds" (content alernate). Or, call out to various resources in 
(x)html. One <content> allows sufficient granularity for accessible 
alternatives to be referenced by <link>.

* allow any XML, base64, and @src in <content>. Disagreement will 
continue about whether MIME is appropriate for @type. Don't let it be a 
stumbling block right now. Limiting the XML allowed in <content> will 
only ensure that new values are inserted in @type.

* <title>, <tagline>, <copyright>, <info>, <summary> become "Textual 
Constructs". Plain text and (X)HTML are ok. That's it. It might get 
stripped.

Robert Sayre