Subject: PaceReformedContentRedux

From: Tim Bray <[email-masked]>
Date: Mon, 13 Sep 2004 12:49:12 -0700

Edited this proposal to implement some comments and some offline 
discussion with Sam.  The main change is that there's no default value 
for type= on atom:content or an atom Text Construct.  If type= isn't 
there, it's just text without markup designed to be rendered, software 
can collapse space and use proportional fonts and so on.  More or less 
what I thought "text/plain" meant before others pointed out that it 
didn't.  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 13 Sep 2004 18:27:11 -0400

> what I thought "text/plain" meant before others pointed out that it 

Should the value text/plain be retained for Text Constructs?

     When present, the value MUST be one of "text/plain", "text/html",
     or "application/xhtml+xml".

If so, do we expect it to be flowed or fixed?  Are proportional space 
fonts OK?

I'd recommend dropping text/plain from Text Constructs.

  - - -

I'm troubled by the SHOULD in:

     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.

Finally, does this apply when the @src attribute is specified?  Or would 
one expect to find the full (x)html page there?

  - - -

Despite these questions/comments, I'm supportive of this Pace.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Mon, 13 Sep 2004 20:27:15 -0700

> I'd recommend dropping text/plain from Text Constructs.

My read of the RFCs is that text/plain is not actively harmful, I'd 
leave it in and let the implementors work out what to do with it.  But 
it's not a big deal, if a couple more people speak up and say "take out 
text/plain" let's do that and shed no tears.

>     validly appear directly within an HTML or XHTML "body"

This is a SHOULD because it's I think MUSTs should be straightforwardly 
testable, and it's tricky & expensive to do the kind of validity test 
here ("can XXX validly appear in html:body?").  And if someone inserts 
something that really shouldn't appear under html:body, the nature of 
HTML renderers is that it'll probably come out more or less OK anyhow.

> Finally, does this apply when the @src attribute is specified?  Or 
> would one expect to find the full (x)html page there?

I don't see any reason why it should be different. -Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 14 Sep 2004 08:05:25 +0200

> If so, do we expect it to be flowed or fixed?  Are proportional space  

Can't we allow for MIME type parameters to be used within the @type  
attribute? If so, it's just to say that 'type="text/plain"' preserves line  
breaks, while 'type="text/plain; format=flowed"' don't.

> one expect to find the full (x)html page there?

I would expect the full (X)HTML page there. That should probably be  
mentioned.

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

---

From: Sam Ruby <[email-masked]>
Date: Tue, 14 Sep 2004 09:16:46 -0400

> text/plain" let's do that and shed no tears.

If left in, the Pace should explain what text/plain means... flowed or 
fixed... are proportional space fonts OK?

Note: I'm not saying disallow it for content.  I just don't see a need 
for a fourth option (omitted, html, xhtml, AND plain) for titles.

> HTML renderers is that it'll probably come out more or less OK anyhow.

It would be neither tricky nor expensive for the feedvalidator to 
implement.  In any case, I will implement the same checks whether it is 
a SHOULD or MUST, the difference is whether the result is a warning or 
an error.

Inserting a <title> element will cause the rest of the page to not 
display.  For aggregators that display entries one at a time, this is 
not a big deal.  For aggregators like bloglines... it would be very bad.

Two years ago[1], Radio used to double encode descriptions, and then 
double decode them... and pass the result to the browser which would 
then attempt to decode the results a third time.  Those of us who used 
RadioUserland and often discussed RSS tags (like <title>) or HTML (like 
<title>) would often cause great pain to other RadioUserland users.

> I don't see any reason why it should be different. -Tim

Again, making it clear would be a good thing.  I'm confortable 
transmitting fragments of a page within a feed, but somehow I feel that 
if I were to refer to an entry in isolation, I would tend to want to 
refer to the whole page, and not create another resource.

- Sam Ruby

[1]<http://radio.userland.com/developer/techNotes/aggregatorDoubleDecodingBugFixed>

---

From: Eric Scheid <[email-masked]>
Date: Wed, 15 Sep 2004 00:13:24 +1000

> refer to the whole page, and not create another resource.

firstly, we already have a mechanism for referring to a full (x)html page.

secondly, just how is an aggregator like bloglines meant to handle the
content found at atom:content/@src? This is just a bigger version of the
problem of putting <xhtml:title/> as a tag inside <atom:title>.

-1 to @src resources being full xhtml pages.

e.

---

From: Antone Roundy <[email-masked]>
Date: Tue, 14 Sep 2004 08:28:13 -0600

> I would expect the full (X)HTML page there. That should probably be 
I would probably expect not to find full (x)html...or to be more 
precise, I'd prefer to find exactly what would have appear in the 
<content> element if the publisher hadn't decided to separate it out to 
keep the feed smaller.  Putting full (x)html there would make the 
processing significantly different, and might be a better fit with a 
<link> than with content/@src.  A related point that's been mentioned 
before in a different context is that <link> might to point to a 
webpage with site navigation and everything, while an element that 
points to externally stored content should really just be pointing to 
the content without all the website context surrounding it.

---

From: Robert Sayre <[email-masked]>
Date: Tue, 14 Sep 2004 13:56:12 -0400

> -1 to @src resources being full xhtml pages.

I would expect to find a resource of type text/html, 
application/xhtml+xml, etc. That might be a full html document, because 
that's what the MIME type means. I would expect an aggregator like 
bloglines to handle it similarly to a atom:content/@src pointed at a PDF 
resource.

Robert Sayre

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 14 Sep 2004 20:39:17 +0200

On Tue, 14 Sep 2004 08:28:13 -0600, Antone Roundy <[email-masked]>  
wrote:

> keep the feed smaller.

I would want that as well. I'd still expect it to be a full XHTML  
document, but without the chrome. Would you want to find just the content  
of <content> at the end of that URI? That is, no DOCTYPE, no XML  
declaration and no <head>?

> Putting full (x)html there would make the processing significantly
> different, and might be a better fit with a <link> than with  
> content/@src.

True.

> A related point that's been mentioned before in a different context is
> that <link> might to point to a webpage with site navigation and
> everything, while an element that points to externally stored content
> should really just be pointing to the content without all the website
> context surrounding it.

I agree.

---

From: Tim Bray <[email-masked]>
Date: Tue, 14 Sep 2004 12:39:46 -0700

On Sep 14, 2004, at 10:56 AM, Robert Sayre wrote:

> application/xhtml+xml, etc. That might be a full html document, 
> because that's what the MIME type means. I would expect an aggregator 
> like bloglines to handle it similarly to a atom:content/@src pointed 
> at a PDF resource.

I almost agree, but don't.  When you dereference a URI and you get a 
header from the server saying "application/xhtml+xml" and you're a 
general-purpose web browser, you're within your rights to declare an 
error if it doesn't start with <xhtml:html>.  But the semantic of 
Atom's type= attribute is different from the Mime Content-type: header, 
and is given by the Atom RFC's.  --Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 15 Sep 2004 00:02:18 +0200

> fixed... are proportional space fonts OK?

I agree. This needs to be stated. And because we have a standard mechanism  
to express that plain text is flowed, I think 'text/plain' without that  
parameter should be fixed:

<url: http://www.ietf.org/rfc/rfc2646.txt>

   <content type="text/plain">

means fixed text, while

   <content type="text/plain; format=flowed">

means flowing text.