Subject: Re: PaceReformedContent3 - @type and @mode

From: Antone Roundy <[email-masked]>
Date: Fri, 1 Oct 2004 11:35:08 -0600

On Wednesday, September 29, 2004, at 06:15  PM, Dare Obasanjo wrote:
> Then there is the fact that both attributes can be
> combined in ways that don't make logical sense but
> would in fact be valid (e.g. mode='xml' &
> type='text/html' or mode='text/plain' and
> mode='base64' from Atom 0.3).

Perhaps the problem is that we have the "wrong" names for @mode values. 
  There's a parallel for what we're doing here in MIME.  <content 
type="application/xhtml+xml" mode="xml"> does not map to:

Content-Type: application/xhtml+xml
Content-Transfer-Encoding: xml

but perhaps:

Content-Type: application/xhtml+xml
Content-Transfer-Encoding: 8bit

"base64" and "escaped" are both fine names--both tell the consuming 
application exactly what to do with the content to turn it into the 
type specified by @type.  But instead of saying, "you don't have to 
transform this", "xml" reads as if it were talking about the content 
type.  Maybe a name like "literal", "inline", "unencoded"...would 
communicate the idea better.  And in fact, "encoding" might be more 
obvious than "mode".

But that will all be moot if PaceReformedContent3 does away with @mode, 
which I don't think is a bad idea.  I just bring it up in case anyone 
was having trouble letting go of @mode, even though they were 
dissatisfied with it.

BTW, I don't see a problem with text/plain as base64, for example. 
text/html as xml is problematic, because even if all tags are closed 
properly, etc., the HTML elements, appearing without namespaces, would 
look like they were in Atom's namespace (unless the feed didn't use a 
default namespace).  But I don't see that as a weakness of the system.  
It's similar to the reason for having transfer encodings in MIME--some 
data simply can't be transferred unencoded in some circumstances (over 
7 bit networks...).