Subject: Consensus around PaceReformedContextRedux?

From: Tim Bray <[email-masked]>
Date: Mon, 20 Sep 2004 22:46:56 -0700

I proposed this here 
(http://imc.org/atom-syntax/mail-archive/msg09866.html) incorporating 
some of the commentary on PaceReformedContent, which was mostly 
positive.

There were really only two significant discussion threads: Sam Ruby 
pushed back on the inclusion of text/plain 
(http://imc.org/atom-syntax/mail-archive/msg09870.html) in Text 
Constructs, and I think he's right.  So I updated the pace to lose it 
(http://www.intertwingly.net/wiki/pie/PaceReformedContentRedux).

There was some discussion around requiring the target of <content 
src="foo"> to be a complete document, but this failed to gain any 
traction.

While this isn't officially on our ToDiscuss list at the moment, I 
checked with Paul and we agreed that it would be worth-while to do a 
consensus trial-balloon, because if we can slip this in, it'll make a 
dent in the issues list and tidy up the format spec quite a bit.

So...... if you have a big problem with this proposal, now is the time 
to speak up.  After, of course, reviewing the discussion to date.  -Tim

---

From: Phil Ringnalda <[email-masked]>
Date: Tue, 21 Sep 2004 00:44:36 -0700

On Mon, 20 Sep 2004 22:46:56 -0700, Tim Bray <[email-masked]> wrote:
> to speak up.  After, of course, reviewing the discussion to date.

I hate to speak up, but: while I quite like every other aspect of the
Pace, the handling of application/xhtml+xml looks a lot like sweeping
under the rug. I don't remember seeing any really useful conclusions
about the element used to tack on the XHTML namespace, whether it's
something that is intended as part of the markup or something just to
hold a namespace, that should be stripped, and having the spec have
two examples of XHTML use, neither of which include elements, and thus
don't use a namespace at all, while the spec text only says "SHOULD be
... XHTML text and markup that could validly appear directly within an
... XHTML "body" element", for which bare text barely qualifies (as
XHTML 1.0 Transitional, only) doesn't seem very conclusive.

I'm afraid that if we really want application/xhtml+xml to interop,
we've got to grasp the nettle of what goes around it, either by saying
that you have to figure out how to add a namespace to your <p>s, or
that whatever the outside element is, it will be stripped by
receivers.

Phil Ringnalda

---

From: Martin Duerst <[email-masked]>
Date: Tue, 21 Sep 2004 17:03:17 +0900

These are the issues I see for PaceReformedContentRedux:

- "Text Constructs MAY have a "type" attribute, whose value indicates
    the media type of the content."

   On various occasions, I started to write a mail about my concerns on
   the issue of what I consider a potentially dangerous misuse of media
   types on various occasions, but got stuck. Seeing the above sentence,
   I think I can clearly express at least one part of my concerns:

   As it stands, the above sentence is clearly wrong. The type attribute
   *looks like* a media type, but it *is not* a media type. It may feel
   to some, in some respects, like a media type, but it isn't, and
   calling it a media type will only lead to confusion.

   As a simple example, the actual media types 'text/html' and
   'application/xhtml+xml' do not differ in how many times you have
   to escape markup to make it become literal; in an actual 'text/html'
   file as well as in an actual 'application/xhtml+xml' file,
       <h1>How to use &lt;hr /></h1>
   looks the same/means the same.

   So preferably use different values for @type (if there are only two,
   that shouldn't be too difficult), or *at least* make it very clear
   that these are NOT media types.

- The examples seem to be out of synch:
   - "<summary type="application/xhtml+xml">Don&#x2019;t!</summary>":
     this doesn't need any type, and will probably confuse readers if it
     has one. Same for:
     <title type="application/xhtml+xml">How to use &lt;hr /></title>
     and a few others.
   - <content type="image/gif">
        R0lGODlhBQAFAJEAAAAAAP////8AAAAAACwAAAAABQAFAAACBYyPJslRADs=
        </content>
     isn't allowed. Or there are inconsistencies in the Pace otherwise.
     Better to clean them up before asking for consensus.
   - There isn't much in terms of examples that show actual markup
     with application/xhtml+xml.

Regards,    Martin.

At 22:46 04/09/20 -0700, Tim Bray wrote:

>I proposed this here 
>(http://imc.org/atom-syntax/mail-archive/msg09866.html) incorporating some 
>of the commentary on PaceReformedContent, which was mostly positive.
>
>There were really only two significant discussion threads: Sam Ruby pushed 
>back on the inclusion of text/plain 
>src="foo"> to be a complete document, but this failed to gain any traction.
>
>While this isn't officially on our ToDiscuss list at the moment, I checked 
>with Paul and we agreed that it would be worth-while to do a consensus 
>trial-balloon, because if we can slip this in, it'll make a dent in the 
>issues list and tidy up the format spec quite a bit.
>
>So...... if you have a big problem with this proposal, now is the time to 
>speak up.  After, of course, reviewing the discussion to date.  -Tim

---

From: Tim Bray <[email-masked]>
Date: Sun, 26 Sep 2004 16:16:47 -0700

>   calling it a media type will only lead to confusion.

I take your point, but actually the value of type= *is* the name of a 
media type.  It's not being used in the same way that the same names 
are used in MIME-header applications; as you point out, in Atom there 
are special treatment and encoding rules attached to particular media 
types, which is not the case in MIME headers.

It's actually worse than you point out, because it's not OK to get an 
HTTP transmission with a media type of application/xhtml+xml whose body 
consists solely of

<p xmlns="http://www.w3.org/1999/xhtml">An important story which you 
should read.</p>

But in Atom, that would be OK.  So, Atom is using the same names that 
are used for real Internet media types, but in a different way.  
However, I don't think this is going to cause any confusion or errors.  
Do you disagree?

>     has one.

I agree.

> Same for:

No, on this one I disagree.  Because if you had text/html, you'd have 
to say "&amp;lt;hr/>".  But I agree that the specification should 
probably highlight this, because the point isn't obvious.

>     isn't allowed

I disagree.  Why isn't this allowed?

>     with application/xhtml+xml.

Agreed.  I'll add one. -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 26 Sep 2004 18:00:49 -0700 (PDT)

> However, I don't think this is going to cause any

Yes. Atom currently implies to consumers that the
contents of a content construct can be dispatched to
the appropriate MIME handler for that construct.
However it is quite clear from the various examples
floating around that people don't actually expect to
do this. For example, no fully compliant MIME handler
for application/xml+xhtml should accept the content of
an Atom content construct as is it won't have a DTD
nor will it typically begin with the correct root
element for XHTML. 

=====
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: Tim Bray <[email-masked]>
Date: Sun, 26 Sep 2004 18:40:30 -0700

> the appropriate MIME handler for that construct.

Would it address your concerns if we specified clearly that although we 
re-use the same labels, this does not imply that the <atom:content> can 
be dispatched to a "fully compliant MIME handler"?  Or do we need to 
invent new labels?  -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Sun, 26 Sep 2004 19:04:59 -0700 (PDT)

> be dispatched to a "fully compliant MIME handler"? 

I'd rather invent new labels. There is less room for
assumption if the content is described as 'text',
'html' or 'xhtml' than 'text/plain', 'text/html', or
'application/xml+xhtml'. 

=====

__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo

---

From: Tim Bray <[email-masked]>
Date: Sun, 26 Sep 2004 19:35:57 -0700

> 'html' or 'xhtml' than 'text/plain', 'text/html', or

I can see Dare's point.  Anyone disagree?  I'm inclined to revise the 
Pace. -Tim

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 26 Sep 2004 19:52:33 -0700

At 7:04 PM -0700 9/26/04, Dare Obasanjo wrote:
>I'd rather invent new labels.

+1. We see this in the security area: if you use a label that is too 
much like an existing label, users (and, unfortunately, all to many 
implementers) will assume they are used in the same way. Making them 
different will help keep them separate in people's minds.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Eric Scheid <[email-masked]>
Date: Mon, 27 Sep 2004 13:09:18 +1000

On 27/9/04 12:35 PM, "Tim Bray" <[email-masked]> wrote:

> Pace.

I'm undecided, but I can see we lose text/*, and also *xml. The latter is no
big problem, we just expand Dare's set of labels to {text,html,xhtml,xml}.
The former will pose a problem for some edge case implementations, possibly
moreso on the protocol side than the format [1].

Also, if @type is no longer to contain media type labels, the attribute
needs to change name. Since it drives the encoding mode I suggest @mode.

e.

[1] I'm thinking of a possible editor where the user might get to select
from a number of text psuedo-markup formats (such as wiki, markdown,
textile, etc), and their publishing system triggers off the @type to
transform that posted text into xhtml. But then I'm also thinking something
funky like that might go into extensions.

---

From: "Roger B." <[email-masked]>
Date: Sun, 26 Sep 2004 22:51:12 -0500

> Pace

Tim: Agree with Dare... "text", "html", and "xhtml" do the job without the
baggage.

--
Roger Benningfield

---

From: Sam Ruby <[email-masked]>
Date: Sun, 26 Sep 2004 23:52:25 -0400

> I can see Dare's point.  Anyone disagree?  I'm inclined to revise the 

At which point, the gap between PaceReformedContextRedux and 
PaceSimpleContentType closes a bit more.

In PaceSimpleContentType, type means mime type.  Those things without a 
type are defined via a mode parameter.

I'm not thrilled with the name mode.  But then again, I'm not trilled 
with type being perhaps a mime type or perhaps something Atom specific.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Mon, 27 Sep 2004 12:03:51 +0900

At 19:52 04/09/26 -0700, Paul Hoffman / IMC wrote:
>+1. We see this in the security area: if you use a label that is too much 
>like an existing label, users (and, unfortunately, all to many 

Yes indeed. Another issue is that at some point, a third spec
(MIME being the first, and Atom the second) comes around which
wants to do something new, but reuse stuff from both MIME and
Atom.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Mon, 27 Sep 2004 12:11:24 +0900

At 16:16 04/09/26 -0700, Tim Bray wrote:

>media type.

"the value of @type is the name of a media type" already is much
better than "the value of @type indicates the media type of the
content". "the value of @type happens to look like the name of a
media type, but is only vaguely related to a media type", with
more explanations, would be even better.

>It's not being used in the same way that the same names are used in 
>MIME-header applications; as you point out, in Atom there are special 
>treatment and encoding rules attached to particular media types, which is 
>not the case in MIME headers.

Of course MIME headers also have special rules attached. Not to
subtypes, but to 'major' types (e.g. text/*).

>It's actually worse than you point out, because it's not OK to get an HTTP 
>transmission with a media type of application/xhtml+xml whose body 
>consists solely of
>

Yes indeed! And even worse: many documents conforming to
application/xhtml+xml aren't legal at this point in Atom
(all those that have a DOCTYPE, unless we would invent and
describe a special convention to encode the doctype, which
I guess would be a mess).

>But in Atom, that would be OK.  So, Atom is using the same names that are 
>used for real Internet media types, but in a different way.

It may or may not cause confusion. At the very least, the
spec has to be very clear on what's doing on, and that this
is against potential expectations. But I agree that it's better
to have separate labels.

>No, on this one I disagree.  Because if you had text/html, you'd have to 
>say "&amp;lt;hr/>".  But I agree that the specification should probably 
>highlight this, because the point isn't obvious.

ok.

>I disagree.  Why isn't this allowed?

The pace says "Text Constructs MAY have a "type" attribute, whose value
indicates the media type of the content. When present, the value MUST be
one of "text/html" or "application/xhtml+xml"."

Seems clear enough to me that image/gif isn't allowed.

>Agreed.  I'll add one. -Tim

Great, thanks.     Martin.

---

From: Tim Bray <[email-masked]>
Date: Sun, 26 Sep 2004 22:36:31 -0700

> one of "text/html" or "application/xhtml+xml"."

Ah, but in PaceReformedContent*, <atom:content> isn't a Text Construct, 
precisely so that you can do this kind of thing. -Tim

---

From: Walter Underwood <[email-masked]>
Date: Mon, 27 Sep 2004 07:53:07 -0700

--On Sunday, September 26, 2004 7:35 PM -0700 Tim Bray <[email-masked]> wrote:
> I can see Dare's point.  Anyone disagree?  I'm inclined to revise the Pace. -Tim

I agree, new labels.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Graham Parks <[email-masked]>
Date: Mon, 27 Sep 2004 07:59:05 -0700

>I can see Dare's point.  Anyone disagree?  I'm inclined to revise the 

Rough proposal: Revive the mode element, but use it to enumerate all of the special cases in the pace (and only require type when necessary):

1. no @mode
2. mode="html"
3. mode="text" type="..."
4. mode="xml" type="..."
5. mode="base64" type="..."

Also possibly:
6. mode="xhtml"
7. mode="external" type="..." src=""

How does that sound?

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 27 Sep 2004 08:07:11 -0700 (PDT)

--- Graham Parks <[email-masked]> wrote:
> 
> Rough proposal: Revive the mode element, but use it
> to enumerate all of the special cases in the pace
> (and only require type when necessary):
> 
> 1. no @mode
> 2. mode="html"

How does this proposal deal with the problem that the 
type attribute implies that it is a MIME type when it
is not? 

Also I've always thought the mode attribute was a
ridiculously overengineered hack. I fail to see what
it exacly buys us now. Can you provide the rationale
for your proposal? 

=====

__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com

---

From: Eric Scheid <[email-masked]>
Date: Tue, 28 Sep 2004 01:14:30 +1000

On 28/9/04 12:59 AM, "Graham Parks" <[email-masked]> wrote:

> Rough proposal: Revive the mode element, but use it to enumerate all of the
> special cases in the pace (and only require type when necessary):
> 
> 1. no @mode
> 2. mode="html"

+1

While remembering we needed to allow for xml content, I'd forgotten we need
to specify the xml type.

out of curiosity, what are the various text/* mime types, apart from
text/plain and text/xml (shudder)?

e.

---

From: Graham Parks <[email-masked]>
Date: Mon, 27 Sep 2004 08:27:36 -0700

>type attribute implies that it is a MIME type when it

Because you don't use a mime type when you're not using them properly. HTML looks like this:

<content mode="html">...</content>
or
<content mode="xhtml">...</content>

See, no misleading type attribute.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Tue, 28 Sep 2004 01:30:39 +1000

> it exacly buys us now. Can you provide the rationale

That was a different mode attribute.

This mode attribute is just the type attribute renamed, with the syntax
*you* suggested.

As you say, the thing we stuffing into @type (or @mode, or @whatever) are
not MIME types, and since we *are* using an attribute named 'type' elsewhere
for *exactly* that purpose (stuffing actual and real MIME types into, and
properly so), it would behove us to change the name of the attribute.

What is *your* suggestion for the name of the attribute in question?

e.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 27 Sep 2004 08:35:44 -0700 (PDT)

--- Graham Parks <[email-masked]> wrote:
> 
> Because you don't use a mime type when you're not
> using them properly. HTML looks like this:
> 

Unless I misread your email it still had a type
attribute. So the same problem exists. 

All your proposal does is add an extra layer of
unnecessary complexity in determining how to process
the children of the atom:content element while still
leaving the original problem intact. 

=====

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

---

From: Graham Parks <[email-masked]>
Date: Mon, 27 Sep 2004 08:52:03 -0700

>attribute. So the same problem exists.

Yes, but it's only used when it's accurate and no special-case processing is to be done.

>leaving the original problem intact.

Actually quite the opposite. The processing required is now entirely keyed off the mode attribute.

Graham

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 27 Sep 2004 18:06:32 +0200

* Graham Parks wrote:
>Rough proposal: Revive the mode element, but use it to enumerate all
>of the special cases in the pace (and only require type when necessary):
>
>1. no @mode
>2. mode="html"

Odd. Isn't this about how Atom implementations are supposed to extract
the actual content of an element? I also do not really understand what
the difference between "html" and "xhtml" would be, or the difference
between "xhtml", "xml" and "text" as far as processing is concerned.
The "extermal" mode seems to be implied by the presence of "src", no?

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 27 Sep 2004 09:11:16 -0700 (PDT)

--- Graham Parks <[email-masked]> wrote:
> Actually quite the opposite. The processing required
> is now entirely keyed off the mode attribute.

Incorrect. The way I'd process 

1.) mode='html' type='text/plain'
2.) mode='html' type='application/xml+html'
3.) mode='html' type='text/html'

would be completely different even though they have
the same value for the mode attribute. 

It seems you don't understand the problem I raised. So
I'll try to explain it in more detail. When I see
content such as (2), it implies that I can pass the
content to an XHTML compliant processor such as a Web
browser which will render it appropriately when I pass
along the appropriate MIME type. However this should
fail in almost every instance that (2) is used in the
wild today and how it has been suggested that it
should be used by folks on this list. 

There's the separate issue of the fact that existing
Atom specs require processing two attributes to figure
out how to dispatch the content which seems
unnecessary to me especially since the attributes can
be combined in silly ways like in the example in (1)
above. 

=====

---

From: Graham Parks <[email-masked]>
Date: Mon, 27 Sep 2004 10:02:30 -0700

>the same value for the mode attribute. 

Dare, these options don't exist. The type attribute is not used and has no purpose with mode="html". If it's html mode, it is html. Also the numbering used in my proposal matches the bullet list in PaceReformedContextRedux. Read the two together and get back to me.

Graham

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 27 Sep 2004 10:23:05 -0700 (PDT)

--- Graham Parks <[email-masked]> wrote:
> 
> Dare, these options don't exist. The type attribute
> is not used and has no purpose with mode="html". If
> it's html mode, it is html. Also the numbering used
> in my proposal matches the bullet list in
> PaceReformedContextRedux. Read the two together and
> get back to me.

Reading the Pace and your rules, I still think the
rules are too complex for little justifiable reason.
However I am way too busy this week to follow this
discussion deeply. 

Currently I'm -1 on PaceReformedContentRedux. 

Similarly I am -1 on PaceSimpleContentType for a
variety of reasons including 

(i) consumers have to peak at the content before
knowing how to dispatch on it in mode='xml' 
(ii) in practice people are either syndicating html or
xhtml and I'd like to see that enshrined into the Atom
spec instead of lumping xhtml with all xml
vocabularies. 

PS: I agree with the spirit of both Paces but don't
think they hit the sweet spot in simplifying the mess
in the current Atom draft. 

=====

---

From: Tim Bray <[email-masked]>
Date: Mon, 27 Sep 2004 10:42:24 -0700

I observe that per RFC2045, the production for the media-type is

     content := "Content-Type" ":" type "/" subtype
                 *(";" parameter)

that is to say, the "/" is not optional.  Thus, I propose that for the 
value of the type attribute, the following three rules apply

0. if it's not there, use the PaceReformedContentRedux rules.
1. if it's "HTML", do what PaceReformedContentRedux says for 
"text/html"; i.e. no child elements, text content can be sent to an 
HTML processor, should be suitable for inside html's <BODY>
2. if it's "XHTML", do what PaceReformedContentRedux says for 
"application/xhtml+xml", the actual content, which may include child 
elements, should be suitable for inside <xhtml:body>
3. Otherwise it's a real internet media type, with the restrictions 
from PaceReformedContentRedux (which now having re-read 2045, I see 
should be rephrased as "must be an RFC2045 'discrete-type'")

Note that "HTML" and "XHTML" are in upper-case to make it even more 
obvious that they are not actually internet media types.  They can be 
used safely since, lacking a "/", they can't actually be media types.  
-Tim

---

From: Graham Parks <[email-masked]>
Date: Mon, 27 Sep 2004 11:37:59 -0700

>used safely since, lacking a "/", they can't actually be media types.  

That's as good as my suggestion, I think.

If you're rewriting the Pace, can you tidy up the section about the src attribute? It seems to talk around there being two different, mutually-exclusive modes withough actually saying that. It's very weird to read.

Graham