Subject: Re: PaceReformedContent3

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Oct 2004 01:24:20 +0200

On Thu, 30 Sep 2004 08:35:52 +0900, Martin Duerst <[email-masked]> wrote:

> I'd prefer somebody come up with a special escaping syntax that only
> escapes the doctype part. We could even do this with something like:
>     <content type='' doctype=''>

XSLT does this already, and it works rather fine. It's done with the  
<xsl:output> element's 'doctype-system' and 'doctype-public' attributes:

<url: http://www.w3.org/TR/xslt.html#output>

Maybe Atom can adopt these attributes in the <content> element? I would  
not oppose that, at least.

-- 
Asbjørn Ulsberg    -=|=-     http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Oct 2004 01:43:24 +0200

On Mon, 27 Sep 2004 23:10:59 -0700, Tim Bray <[email-masked]> wrote:

> I just cooked this up, it embodies the "HTML"/"XHTML" notion, plus  
> incorporating comments from Martin and Graham.

I don't like the overloading of @type. I think MIME types should go all  
the way, but I don't mind it so much that I'll halt consensus over it.

What I don't understand is the 'TEXT' type. How does this differ from  
'text/plain'? At least, with 'text/plain', you can add MIME type  
parameters, while I guess this is disallowed for 'TEXT'. Am I correct?

What do we gain by using the four uppercase letters 'TEXT' from using the  
MIME type 'text/plain' (optionally with parameters)?

As a side-note, I'd like to mention again my idea of grouping popular MIME  
types within the four content modes mentioned in this pace. The four modes  
are:

   - Escaped markup
   - XML
   - Plain text
   - Base64-encoded content

I'd like to see ordinary MIME types used, but grouped in this way in the  
specification:

   = Escaped markup =

   text/html

   = XML =

   */*+xml, */xml

   = Plain text =

   text/* (but not text/html)

   = Base64 =

   Pretty much everything else

We could and should of course add more known MIME types on the way, but as  
we're moving in the «need to parse and check the @type  
attribute»-direction anyway, I don't see why we can't go all the way.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 2 Oct 2004 18:04:30 -0600

On Saturday, October 2, 2004, at 05:43  PM, Asbjørn Ulsberg wrote:
> The four modes are:

Is there a difference between the XML mode and the plain text mode?  In 
either, anything that looks like markup but isn't (eg. you want the 
user to see <blink>, not to get blinking text) has to be escaped.  
Plain text can't contain actual markup, but that's a matter of the 
content type, not the mode.

Antone

P.S. Is there any way to search the mailing list archive? I find myself 
vaguely remembering things having been discussed before, but not 
knowing a quick way to find them.

---

From: Dare Obasanjo <[email-masked]>
Date: Sat, 2 Oct 2004 17:37:56 -0700 (PDT)

> parameters, while I guess this is disallowed for

(a) Content that is text/plain may contain characters
that are not valid XML characters. Specifically a
number of text/plain documents on the Web [such as
IETF RFCs] contain form feed characters which are
illegal in XML. 

(b) Using MIME type parameters is a lot of UNNECESSARY
complexity to push on clients. 

> MIME type 'text/plain' (optionally with parameters)?

(a) Less ambiguity. 

(b) Less complexity for content producers and feed
consumers. 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #23
I will keep a special cache of low-tech weapons and train my troops in their use. That way -- even if the heroes manage to neutralize my power generator and/or render the standard-issue energy weapons useless -- my troops will not be overrun by a handful of savages armed with spears and rocks.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

---

From: Walter Underwood <[email-masked]>
Date: Sat, 02 Oct 2004 17:39:27 -0700

--On Saturday, October 2, 2004 6:04 PM -0600 Antone Roundy <[email-masked]> wrote:
>
> P.S. Is there any way to search the mailing list archive? I find
> myself vaguely remembering things having been discussed before, but
> not knowing a quick way to find them.

On Yahoo or Google, you can use this:

  site:imc.org inurl:atom-syntax -intitle:"archive of" your query here

Hint to the archive maintainer: add a robots meta tag with noindex
to the index pages. Robots will still follow the links to the
actual messages.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 3 Oct 2004 09:09:48 -0700 (PDT)

--- Asbjørn Ulsberg <[email-masked]> wrote:
> 
> > Specifically a number of text/plain documents on
> the Web [such as
> They of course need to be escaped, but that's the
> natural process of  
> putting _anything_ into an XML document. 

Wrong. They are ILLEGAL characters in XML. There is no
escaping them in a non-application specific way. So
far the consensus I've seen when this was brought up
was to base64 encode text/plain content. 

> > (b) Using MIME type parameters is a lot of
> UNNECESSARY complexity
> > to push on clients.
> 
> But still, 'format=flowed' is very useful. How is
> whitespace supposed to  
> be handled when @type is equal to TEXT? When using
> 'text/plain' with and  
> without 'format=flowed', this is very explicit.
> Without this parameter,  
> the whitespace is preserved and static, with it
> present, the text flows.

The spec can have rules for how the value of the
atom:content element should be processed when
type='text'. This seems a lot simpler and more
straightforward than requiring clients to support MIME
type parameters. 

> >
> > (a) Less ambiguity.
> 
> What is ambigous with 'text/plain', exactly?

The fact that you just got confused about the fact
that text/plain has characters that are illegal in XML
versus 'needing to be escaped' speaks volumes to me. 

It implies you and many others like you would expect
that you could just emit text/plain documents in XML
files without base64 encoding it or stripping illegal
characters  thus causing failures in consumers that
use conformant XML parsers. 

A large number of text/plain documents are not legal
content for an XML file. 

> No, they need to check and parse the value of @type
> no matter what we do.  
> I don't understand how it's more difficult to check
> for the occurence of  
> 'text/plain' or 'text/html' in comparison to 'TEXT'
> or 'HTML'.

That comment was specific to supporting MIME type
parameters which is a lot more complex than switching
on 'text' or 'html'. 

=====

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Oct 2004 13:43:18 +0200

On Sat, 2 Oct 2004 18:04:30 -0600, Antone Roundy <[email-masked]>  
wrote:

> Is there a difference between the XML mode and the plain text mode?

This has been discussed before, and as far as I can remember; yes, there  
is. Typically, I don't remember what at the moment.

> In either, anything that looks like markup but isn't (eg. you want the  

True.

> Plain text can't contain actual markup, but that's a matter of the  

Also true. Maybe 'text/*' (excluding 'text/html') should go into the «XML»  
mode, then? Hm.

> P.S. Is there any way to search the mailing list archive?

I'm currently writing a Windows application for doing just that. It's far  
 from finished, but I can keep the list posted of its progress, if it's  
interesting.

> I find myself vaguely remembering things having been discussed before,  
> but

Same here. It wouldn't hurt having the archive marked up better either, so  
it was easier to crawl and parse with a robot. Also, having the Message-ID  
in the archive would be nice.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 03 Oct 2004 13:37:46 +0200

On Sat, 2 Oct 2004 17:37:56 -0700 (PDT), Dare Obasanjo <[email-masked]>  
wrote:

> (a) Content that is text/plain may contain characters that are not
> valid XML characters.

No. Well, served directly over HTTP, that is the case. But wrapped in XML,  
the same rule applies to all content. It even applies to 'text/*' types in  
the pace as it stands now, as far as I can understand.

> Specifically a number of text/plain documents on the Web [such as
> IETF RFCs] contain form feed characters which are illegal in XML.

They of course need to be escaped, but that's the natural process of  
putting _anything_ into an XML document. The character '<' is accidently  
represented as '&lt;' in XML. That's the way it is, and it has nothing to  
do with the MIME type wrapped up in the XML document. Using a conforming  
tool, you should never have to see the four characters '&lt;' anyway.

> (b) Using MIME type parameters is a lot of UNNECESSARY complexity
> to push on clients.

But still, 'format=flowed' is very useful. How is whitespace supposed to  
be handled when @type is equal to TEXT? When using 'text/plain' with and  
without 'format=flowed', this is very explicit. Without this parameter,  
the whitespace is preserved and static, with it present, the text flows.

>> What do we gain by using the four uppercase letters 'TEXT' from
>> using the MIME type 'text/plain' (optionally with parameters)?
>
> (a) Less ambiguity.

What is ambigous with 'text/plain', exactly? That you can't squeeze all  
characters into the XML document? Well, as mentioned above, this applies  
to all values of @type, no matter what. No content type can change the  
rules of XML.

> (b) Less complexity for content producers and feed consumers.

No, they need to check and parse the value of @type no matter what we do.  
I don't understand how it's more difficult to check for the occurence of  
'text/plain' or 'text/html' in comparison to 'TEXT' or 'HTML'.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 03 Oct 2004 18:44:07 +0900

At 17:37 04/10/02 -0700, Dare Obasanjo wrote:

>--- Asbj$Bxr(Bn Ulsberg <[email-masked]> wrote:
> >

Well, but the current proposal doesn't allow these
characters in places declared as type='text/plain',
because text/plain does not use base64.