Subject: PaceContentAsTextOrHtml; propose slight relaxation

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

This one has me torn in two.  The simplicity is admirable, and in fact 
I haven't seen client software that can handle content other than text 
or HTML in in the wild.  Also, I have come to see the mode= attribute, 
which I think I helped invent, as a hack we'd do better to lose.

On the other hand, I can easily think of lots of applications - some of 
them machine-to-machine - where being able to pump some non-text into a 
feed could prove useful.

On balance, I think I'm against a simplification this extreme.  How 
about a compromise as follows: Type= can be any media type, but if it's 
anything but text/plain, text/html, or application/xhtml+xml, it MUST 
be base64-encoded.  I think this might hit a sweet spot and leave room 
for progress in the market, without placing any onerous burdens on 
implementors.  BUT, if we're gonna do this, we have to have our 
accessibility story straight, it's not OK for people to publish 
all-video feeds with no commentary or explanation.  Is a compulsory 
<atom:description> enough? -Tim

---

From: Eric Scheid <[email-masked]>
Date: Tue, 31 Aug 2004 13:26:47 +1000

On 31/8/04 10:34 AM, "Tim Bray" <[email-masked]> wrote:

> but if it's anything but text/plain, text/html, or application/xhtml+xml, it
> MUST be base64-encoded.
> 

what about other XML formats?

e.

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Aug 2004 20:55:41 -0700

> what about other XML formats?

I like *simple* rules.  These three or base-64.  But, alternatively, if 
the media type ends in +xml, then it MUST be well-formed XML content.  
-Tim

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 31 Aug 2004 08:36:57 +0200

> the media type ends in +xml, then it MUST be well-formed XML content.

That's what I've thought too[1]. We need three content modes, which now is  
expressed by the 'mode' attribute. @mode is indubitably useful, but we can  
say the exact same thing as @mode does with MIME, if we explain it in the  
specification.

If we agree that we have three «content modes» of inline content in Atom  
entries, just like the ones that are explained in PaceContentAsTextOrHtml  
now, we can group MIME types beneath them. Here are the groups I think of:

   XML
   - text/xml
   - application/xml
   - application/*+xml

   Text
   - text/* except text/xml and text/html

   HTML
   - text/html

The processing and publishing rules for the different content modes needs  
to be hashed out a bit more than it is now in the pace, but it practically  
just means that XML content types needs to be namespace-qualified and  
well-formed XML, text content types plain text, and HTML content types  
escaped HTML.

____
[1] <url:  
http://ilrt.org/discovery/chatlogs/atom/2004-08-29.html#T18-04-02>

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Bill de hÓra <[email-masked]>
Date: Tue, 31 Aug 2004 11:51:51 +0100

Tim Bray wrote:

> the media type ends in +xml, then it MUST be well-formed XML content.  -Tim

I think there's room for allowing CDATA sections instead of 
constraining anything that isn't one of those 3 media types to be 
binary, ie those 3 +b64 is overconstrained. Nb: if you base64 you 
still want the media type of the encoded data to allow code that can 
dispatch on more than those 3 values to do so.

+1 to your MUST above.

cheers
Bill

---

From: Norman Walsh <[email-masked]>
Date: Tue, 31 Aug 2004 07:13:59 -0400

/ Tim Bray <[email-masked]> was heard to say:
| On Aug 30, 2004, at 8:26 PM, Eric Scheid wrote:
|
|>
|> On 31/8/04 10:34 AM, "Tim Bray" <[email-masked]> wrote:
|>
|>> but if it's anything but text/plain, text/html, or application/xhtml+xml, it
|>> MUST be base64-encoded.
|>>
|>
|> what about other XML formats?
|
| I like *simple* rules.  These three or base-64.  But, alternatively, if the media type
| ends in +xml, then it MUST be well-formed XML content.  -Tim

That, I think I could accept. Not allowing me to syndicate DocBook
content bothers me. I've got no compelling reason to do so at the
moment, so it doesn't bother me all that much. But it definitely
bothers me.

text as text
html as escaped markup
*+xml as WF XML
anything else as base-64.

+1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Great success is commoner than real
http://nwalsh.com/            | abilities.-- Vauvenargues

---

From: Sam Ruby <[email-masked]>
Date: Tue, 31 Aug 2004 07:38:11 -0400

Tim Bray wrote:
> 
> This one has me torn in two.  The simplicity is admirable, and in fact I 
> haven't seen client software that can handle content other than text or 
> HTML in in the wild.  Also, I have come to see the mode= attribute, 
> anything but text/plain, text/html, or application/xhtml+xml, it MUST be 
> base64-encoded.  I think this might hit a sweet spot and leave room for 
> progress in the market, without placing any onerous burdens on 

If we allow arbitrary mime types into content, then for accessibility 
reasons allowing an alternate (fallback) representation is a good thing 
to have.

What did you mean when you said atom:description?  This pace requires 
one of atom:summary or atom:content to be present.  I don't believe it 
would be practical to require summaries (i.e., such a requirement would 
be routinely ignored).

Perhaps a requirement that all summaries by textual (plain, html, 
xhtml), and summaries be required if content is either missing or 
non-textual would suffice.

- Sam Ruby

---

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

Tim Bray wrote:
> if it's anything but ..., it MUST be base64-encoded.
	-1. This restriction would massively reduce the utility of Atom to
us at PubSub.com. While we currently only distribute "normal" blog content
and SEC Edgar Data, in the future, there is a wide range of other feed types
that we expect to allow people to subscribe to. For instance, we expect to
support a wide variety of structured types like apartment-availability
notices, job postings (in HR-XML), NITF news stories and press releases,
patents and patent applications in PTO/ICE (XML) format, etc. 
	It has been our hope to use Atom as the general "feed" format for
all of the various kinds of entries. By doing so, we would get consistency
across a wide range of applications and make life much easier on application
developers. But, if we are prohibited from using Atom as a general packaging
format for XML-encoded entries, then we're either going to get stuck doing
it anyway or "inventing" something new that will inevitably drift away as
new features are added to it... This is not good. It makes life harder for
us and for anyone trying to work with us. 
	Atom can be used to support a wide variety of applications that
don't actually need to understand exactly what is in the atom:content
element. Given atom:title, atom:author, etc., it becomes possible, for
instance, to construct general content-routing and even storage applications
(atomflow?), that can treat the content as opaque or even as pure-XML and
yet still provide useful indexing, distribution, storage, matching, etc.
services. 
	I realize that having non-html XML in content is going to be
marginally more difficult for script-kiddies to work with when they build a
new aggregator "over-the-weekend"... However, there are things that we can
do to make life easier for them. For instance, it might make sense to
provide an element or attribute that can convey the URI for an XSL Template
that can provide a default conversion of the content to HTML or XHTML...
	Can you state some *clear* benefit for disadvantaging all uses of
XML other than html or xhtml?

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Tue, 31 Aug 2004 11:35:17 -0700

On Aug 31, 2004, at 4:38 AM, Sam Ruby wrote:

> reasons allowing an alternate (fallback) representation is a good 
> thing to have.
>
> would be practical to require summaries (i.e., such a requirement 
> would be routinely ignored).

D'oh, summary, thinko.

> non-textual would suffice.

+1. -Tim

---

From: Norman Walsh <[email-masked]>
Date: Tue, 31 Aug 2004 15:47:59 -0400

/ Sam Ruby <[email-masked]> was heard to say:
| Perhaps a requirement that all summaries by textual (plain, html, xhtml), and summaries
| be required if content is either missing or non-textual would suffice.

+1

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Nothing can exceed the vanity of our
http://nwalsh.com/            | existence but the folly of our
                              | pursuits.--Oliver Goldsmith