Subject: Work Queue Rotation #8, Part PaceReformedContent

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 14:11:33 -0700

This consensus call discusses a bunch of current issues that turn out 
to be related.

Issues list: http://www.intertwingly.net/wiki/pie/AtomPubIssuesList

The Issues:

PaceContentAsTextOrHtml, PaceContentSrc, PaceNukeMultipart, 
PaceSimpleContentType

A good place to start is Pilgrim in response to Sayre: 
http://www.imc.org/atom-syntax/mail-archive/msg09363.html

Then have a look at the last paragraph of this from Ruby: 
http://www.imc.org/atom-syntax/mail-archive/msg09312.html
Which got a couple of +1's.

And then this from Walsh: 
http://www.imc.org/atom-syntax/mail-archive/msg09310.html
which once again got some support.

Finally check out the analysis and the section entitled "Possible Way 
Forward" from Sayre: 
http://www.imc.org/atom-syntax/mail-archive/msg09378.html

Given all the above, I think there is a consensus position lurking in 
here which could simultaneously put all these to bed.  I've written a 
Pace at http://www.intertwingly.net/wiki/pie/PaceReformedContent and an 
outline here.  Yes, having it in two places is conventionally seen as a 
bad thing, but this is big & complicated enough that doing it twice may 
actually help, and differences between this & the pace are probably 
bugs but may be instructive.

1. Only one <atom:content> per entry
2. The mode= attribute is removed
3. The values of the type attribute may be any registered media type 
that does not begin with multipart/
3.1 if the type matches text/html, the content of <atom:content> should 
be text (unescaped tags are an error) which is suitable for handling by 
software that knows HTML and should be able to appear as a child of 
<body>; standard XML escaping means that if (&lt;br>) appears in the 
content, the HTML processor that gets the content will see <br>.
3.2 otherwise, if the type matches text/*, the content of 
<atom:content> is just text (unescaped tags are an error).
3.3 otherwise, if the type matches */*+xml, the content must be 
well-formed XML with the markup assumed to be meaningful to software 
that knows that media type.
3.4 otherwise, the content must be encoded in base64.
3.5 on atom:content, if the type= is absent, it defaults to text/html.
4. <atom:content> may have a src= attribute, in which case it must be 
empty.  In this case, the type= is advisory.  If type=text/* or *+xml, 
the content should be local, i.e. no src=
5. <atom:summary> must be present if <atom:content> is absent, or 
present but empty (given by src=), or encoded in base64.
6. <title>, <tagline>, <copyright>, <info>, <summary> become "Textual 
Constructs".  The only types allowed are text/plain, text/html, or 
application/xhtml+xml.  The spec should include a caution that 
receiving software may skip/strip markup.  On Textual Constructs, if 
type= is absent, it defaults to text/plain

NEXT STEPS:

1. Give this Pace a couple of days to settle down; it's long & complex 
enough that it's nearly certain to contain typos and thinkos, and for 
there to be inconsistencies between the version here and the Pace.  
Report 'em and I'll fix 'em.
2. Subsequently, people who disagree with parts of it are encouraged to 
create variant Paces whose names look like 
PaceReformedContent<someSuffix like "2" or "Mark">, each of which 
includes, near the top, a clear explanation of the differences between 
it and PaceReformedContent
3. If this (or one of the variants mentioned the previous paragraph) 
are accepted, then PaceContentAsTextOrHtml, PaceContentSrc, 
PaceNukeMultipart, PaceSimpleContentType are closed.

---

From: Ken MacLeod <[email-masked]>
Date: 04 Sep 2004 17:49:50 -0500

The text/plain media type[1] allows for the use of line breaks so that
text can be displayed "as-is".  Many non-syndication usages also use
mono-spaced fonts (so text columns line up) and allow page breaks
(form feeds).

In Atom discussion, I've had the impression that people use text/plain
when referring to plain text (a string of XML characters, presumably
without intentional line breaks).

In several proposals that use the text/plain media type, it is not
made clear how line breaks are to be used.  The purpose of this email
is gather suggestions on how to treat line breaks in text/plain.

  <title type="text/plain">This is a one-line title.  Simple.</title>

  <title type="text/plain">There's a line
    break in this title, now what?</title>

  <summary type="text/plain">
    One might wish to have
    one or more paragraphs
    in a summary.

    But depending on your
    implementation, this could
    be one, two, eight, or
    ten lines.
  </summary>

  <content type="text/plain">
    +-------+
    | Input |\
    +-------+ \
               \ +--------+
                \| Output |
                 +--------+
  </content>

Personally, my preference would be to disallow line breaks altogether
and to normalize whitespace in text/plain content so that it appears
as a single string.  That is to say, if you want any formatting
whatsoever, then use markup.

  -- Ken

[1] http://www.ietf.org/rfc/rfc2046.txt

---

From: [email-masked]
Date: Sat, 04 Sep 2004 16:46:01 -0700 (PDT)

> mono-spaced fonts (so text columns line up) and allow page breaks

Line wrap has been an issue for text/plain since its inception. Numerous
proposals have been floated as to how to deal with it. The one that made
it to the standards track is documented in RFC 2646, and adds an
additional parameter which basically says whether or not
the line breaks are to be considered "hard" or "soft".

I strongly recommend that ATOM consider aligning with this mechanism.

				Ned

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 18:36:19 -0700

> I strongly recommend that ATOM consider aligning with this mechanism.

Sounds reasonable, but there's another nasty impedence mismatch.  By 
definition, software that is getting data out of an XML document using 
a conformant XML processor will see line breaks as single NL (U+000A) 
characters. See http://www.w3.org/TR/REC-xml/#sec-line-ends

On the other hand, RFC2046 says in section 4.1.1 that "The canonical 
form of any MIME "text" subtype MUST always represent a line break as a 
CRLF sequence."  So, suppose you have

<summary type="text/plain">one
two</summary>

and you passed what the XML processor gave you as the content of 
<summary> to a highly-2046-conformant software module, that module 
might barf it right back at you.

Q: Is there wiggle room around the word "Canonical?"

Note: I suspect that a lot of real-world software will not barf on a 
naked LF line-end.

It occurs to me that this may be yet another reason why the "text/xml" 
media type is hopelessly, irreparably, broken.  But we already knew 
that. -Tim

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 4 Sep 2004 22:22:24 -0400

Tim Bray wrote:
>4. <atom:content> may have a src= attribute, in which case it must
> be empty.  In this case, the type= is advisory.  If type=text/* or
> *+xml, the content should be local, i.e. no src=
	I can't seem to find discussion that explains why it is
reasonable to require that *+xml content must be local. Can you please
explain the logic for this? Why does it matter?

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 19:47:30 -0700

> explain the logic for this? Why does it matter?

To increase the efficiency of the system, decrease the workload on the 
receiver, allow off-line browsing.  The default should be that if 
you're going to have text in your feed, the text should be in your 
feed.

On the other hand, I just picked this up from one of the 10**9 emails 
on the thread, I forget which now, and it seemed plausible.  If a lot 
of people are fine with it being OK for text to be remote, I'm not 
going to stand in the way.  If it's controversial, I could just pull it 
out of the Pace and we could take it up as a disjoint issue. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Sun, 05 Sep 2004 13:42:30 +1000

>> explain the logic for this? Why does it matter?

I'm curious to know how xml processing instructions would be handled (and
inline entity definitions for that matter), for @src=somefile.xml

eg: if I had an xslt which transformed a foaf.xml into svg.xml, what would I
put into @type?

e.

---

From: [email-masked]
Date: Sat, 04 Sep 2004 20:47:18 -0700 (PDT)

> CRLF sequence."

This requirement was loosened for HTTP. I see no reason why it couldn't
be loosened for ATOM as well.

> So, suppose you have

> might barf it right back at you.

It would if you were talking to an RFC 2046-compliant email system. it is
well understand that conversions are necessary in this case, and perhaps
others.

> Q: Is there wiggle room around the word "Canonical?"

Maybe. The current trend seems to be to take the CRLF restriction as specific
to email. The revision of MIME part IV that is currently out in draft form
makes a start in formalizing this.

> Note: I suspect that a lot of real-world software will not barf on a

Email software in particular is forbidden to treat anything other than CRLF as
a line terminator. This has led to an expectation that bare CR and bare LF
won't terminate lines, and that in turn has caused interoperability problems -
some quite serious - with software that does elect to treat bare LF and bare CR
as line terminators.

> media type is hopelessly, irreparably, broken.  But we already knew

Agreed.

				Ned

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 21:08:58 -0700

> eg: if I had an xslt which transformed a foaf.xml into svg.xml, what 

Well, we already know that in the general case, XML has problems 
packaging other XML.  So, if you're going to need to include an entire 
XML document including the XML & DOCTYPE declarations, src= becomes an 
interesting alternative.  On the other hand, forcing the client to do 
two fetches slows things down and makes you unavailable offline.  So in 
many cases you'd really like to do without the prologue if you could.

In your example, you'd have type="image/svg+xml", right?  -Tim

---

From: Eric Scheid <[email-masked]>
Date: Sun, 05 Sep 2004 15:02:59 +1000

On 5/9/04 2:08 PM, "Tim Bray" <[email-masked]> wrote:

> Well, we already know that in the general case, XML has problems packaging
> other XML.  So, if you're going to need to include an entire XML document
> including the XML & DOCTYPE declarations, src= becomes an interesting
> alternative.  

apart from the extra fetches involved, if I really wanted to be sure an
atom-consumer would receive (say) a contact.vcard, I would do the transform
at my end, rather than hope and pray they have a compatible xslt transformer
at their end.

but apart from xslt funk, @src still looks useful

> On the other hand, forcing the client to do two fetches slows
> things down and makes you unavailable offline.  So in many cases you'd really
> like to do without the prologue if you could.

the two fetches being the @src content + the xlst referenced therein? or do
you mean the feed.atom + content/@src?

I'd expect, as a busy user of end-user software, that my atom consuming
aggregator would pro-actively/pre-emptively fetch any content/@src at the
time of fetching the full feed.

... actually ... if it doesn't then there can be synchronisation problems.
The feed/entry would be whatever was cached when the feed was fetched, but
the content/@src could be more current. This has potential of being quite
annoying.

> In your example, you'd have type="image/svg+xml", right?  -Tim

yep, despite being technically not supported (@type being advisory,
overridden by the http-header). I don't suppose that xslt has any way of
emitting it's own @type, right? (other than root element + namespace)

e.

---

From: Eric Scheid <[email-masked]>
Date: Sun, 05 Sep 2004 15:59:40 +1000

> <atom:content> is just text (unescaped tags are an error).

which disallows any text content which can't be put inside XML such as
form-feed characters.

I don't consider that a loss though. For such an edge case, they can just
use @src :-P

> atom:content MAY have a "src" attribute, whose value MUST be a URI

relative URI? #fragments?

I'd think yes to both.

e.

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 23:24:51 -0700

> be loosened for ATOM as well.

Hah, thanks Ned, I'd forgotten section 19.4.2 of RFC2616, check it out, 
it says that strict MIME environments expect CRLF and you SHOULD give 
it to them, it's a SHOULD because sometimes HTTP can't.  Actually, I 
think that the i18n problems HTTP can have can't occur in Atom because 
XML only has one character set, Unicode.  But, in XML you can have a 
naked CR.  So, I think that replicating the 2616 language is the right 
thing to do (noting as 2616 does that you just broke any DigSig that 
may have been around).

I'll take an action item to add that to PaceContentReformed. -Tim

---

From: Tim Bray <[email-masked]>
Date: Sat, 04 Sep 2004 23:38:53 -0700

> I strongly recommend that ATOM consider aligning with this mechanism.

I can see two options for Atom:

1. Require support for the Format=Fixed/Flowed parameter
2. Assert that in Atom text constructs, Format=Fixed

Without much discussion, I would lean on a strawman basis to #2.  
First, because I suspect a lot of Atom implementations aren't going to 
have 2646 support so it would have to be built from scratch, at some 
cost and lots of chances to get wrong.  Second, because, Atom Text 
Constructs support HTML (via text/html or application/xhtml+xml) which 
gives you all the hard/soft-line-breaking and smart space collapsing 
you could ever want, and many Atom implementations will have decent 
HTML rendering capability, and for text/html, if you strip all the tags 
and flow the text, you usually get a presentation that doesn't surprise 
anyone.

On the other hand, this hasn't been discussed and I could be missing 
something obvious. -Tim

---

From: Martin Duerst <[email-masked]>
Date: Sun, 05 Sep 2004 15:34:41 +0900

>eg: if I had an xslt which transformed a foaf.xml into svg.xml, what would I

You mean you had the xslt as the content? Or the foaf? Whatever
the content is, that's how you label it. If you put the result
in content, then you would label it as SVG.

At least that's how I understand this, but it seems Tim disagrees.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 05 Sep 2004 11:18:01 +0900

At 18:36 04/09/04 -0700, Tim Bray wrote:

>definition, software that is getting data out of an XML document using a 
>conformant XML processor will see line breaks as single NL (U+000A)

[nit: this is LF, not NL]

>On the other hand, RFC2046 says in section 4.1.1 that "The canonical form 
>of any MIME "text" subtype MUST always represent a line break as a CRLF 
>sequence."  So, suppose you have
>
>and you passed what the XML processor gave you as the content of <summary> 
>to a highly-2046-conformant software module, that module might barf it 
>right back at you.
>

Well, to fix this specific case would be easy. We know we get LF from
the XML parser, we can just specify that this is converted to CRLF
before handling to an RFC 2046 software module.

>Note: I suspect that a lot of real-world software will not barf on a naked 
>LF line-end.

My guess is that mileage may vary tremendously here.

>media type is hopelessly, irreparably, broken.  But we already knew that. -Tim

No, this is unrelated. If you send text/xml over SMTP, then you have to
use CRLF, and I guess quite some sofware will fail otherwise. Ned may
know a lot more about this case. If you send text/xml over HTTP, then
HTTP allows all of CR, LF, or CRLF, so you are fine. The main issues
are with gateways from HTTP to SMTP and back.

The more I look at this 'reuse' of media types in Atom, the more I get
scared because we try to do a halfway job at packaging that may work out
so-so for Atom, but may negatively affect the rest of the Internet.
One particular thing I'm fearing is that we suddenly get requests for
media type registrations that say something like "I need this media
type this way, because I want it to behave a certain way in Atom".

This would definitely be the wrong way round.

Regards,    Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 05 Sep 2004 15:55:59 +0200

On Sun, 05 Sep 2004 15:59:40 +1000, Eric Scheid  
<[email-masked]> wrote:

> relative URI? #fragments? I'd think yes to both.

What do you expect clients to do with fragment identifiers when you use  
them?

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

---

From: [email-masked]
Date: Sun, 05 Sep 2004 06:49:57 -0700 (PDT)

> type this way, because I want it to behave a certain way in Atom".

Flipping this around, there are two ways to mitigate this risk:

(1) Register protocol-specific media types for ATOM.

(2) Use a mechanism other than media types for identifying things in ATOM.

But both of these just replace one set of problems with another. With (1) you
have the new issue of media types of a specific sort leaking into other
protocols, with (2) you've really solved nothing since conversion between the
two mechanisms is inevitable.

The bottom line is that protocols really need to be designed to play nicely
with the other children on the net. Nothing exists in isolation any more,
and we get into trouble every time we pretend it does.

				Ned

P.S. Recent issues with media types in the AVT working group have led to a 
rejiggering of the media types registration process to make it clear
protocol-specific registrations are allowed. However, this is really only
intended to deal with things like media types that cannot usefully exist in
isolation. For example, there are media types in AVT that depend on external
packet framing; if you extract the data from the packets and stream it into a
file you end up with garbage.

---

From: Tim Bray <[email-masked]>
Date: Sun, 05 Sep 2004 07:40:50 -0700

On Sep 5, 2004, at 6:55 AM, Asbjørn Ulsberg wrote:

> What do you expect clients to do with fragment identifiers when you 
> use them?

This has breakage potential but basically works.  For example, in HTTP 
the semantics of the fragment identifier are "display starting here".  
In SVG, they're much more precise, identifying a component of the 
image.  What's the problem, Asbjørn? -Tim

---

From: Martin Duerst <[email-masked]>
Date: Mon, 06 Sep 2004 07:02:01 +0900

At 07:40 04/09/05 -0700, Tim Bray wrote:

>On Sep 5, 2004, at 6:55 AM, Asbjorn Ulsberg wrote:
>
>>What do you expect clients to do with fragment identifiers when you use them?
>

Did you mean HTML?

Regards,   Martin.

>In SVG, they're much more precise, identifying a component of the image.

---

From: Tim Bray <[email-masked]>
Date: Sun, 05 Sep 2004 15:30:39 -0700

On Sep 5, 2004, at 3:02 PM, Martin Duerst wrote:

>> For example, in HTTP

Yes. -T

---

From: Martin Duerst <[email-masked]>
Date: Mon, 06 Sep 2004 07:31:17 +0900

>>be loosened for ATOM as well.

Hello Ned,

Sorry, but I don't see the case for *specifically* loosening that
requirement for ATOM.

Are you talking about the ATOM protocol? Or the Atom format?
For the former, my understanding is that this will reuse HTTP, so
any line ending convention would be okay. For the later, it will
usually be served over HTTP, and then again any line endings are okay,
but if sent by mail, what Tim cites below applies.

Regards,    Martin.

>Hah, thanks Ned, I'd forgotten section 19.4.2 of RFC2616, check it out, it 
>says that strict MIME environments expect CRLF and you SHOULD give it to 
>them, it's a SHOULD because sometimes HTTP can't.  Actually, I think that 
>the i18n problems HTTP can have can't occur in Atom because XML only has 
>one character set, Unicode.  But, in XML you can have a naked CR.  So, I 
>think that replicating the 2616 language is the right thing to do (noting 
>as 2616 does that you just broke any DigSig that may have been around).
>

---

From: Martin Duerst <[email-masked]>
Date: Mon, 06 Sep 2004 07:27:41 +0900

>(1) Register protocol-specific media types for ATOM.

It's not the ATOM protocol where these things come up, but the ATOM
format. So probably, it should say 'format-specific' above.

>two mechanisms is inevitable.

I think there is a third alternative:

(3) Clearly distinguish encoding aspects from typing aspects, as it has
     been done in MIME (Content-Transfer-Encoding) and in HTTP.

For embedded content, the content element would have at least two
attributes, (using long explicit names here): media-type and
content-embedding. I think similar proposals have been made in the
past, but they have usually been rejected as 'too complicated'.
I think we could still have the desired simplicity for the average
case by using default rules to derive content-embedding from media-type,
but we would get a much cleaner layering, and avoid dependencies
that may bite us in the future.

Regards,    Martin.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 06 Sep 2004 08:15:28 +0200

> In SVG, they're much more precise, identifying a component of the image.

Is it expected to have any arbitrary XML format with any arbitrary xml:id  
in it to work? If so, what's the definition of «work»? If the resource is  
rendered in a browser widget, is it good enough to give the fragment  
focus, or should the fragment be extracted from the source and then served  
to the widget? What if the resource is not rendered in a browser widget or  
not rendered at all?

---

From: Tim Bray <[email-masked]>
Date: Sun, 05 Sep 2004 23:25:54 -0700

>>> What do you expect clients to do with fragment identifiers when you 
...
> Is it expected to have any arbitrary XML format with any arbitrary 
> xml:id in it to work? If so, what's the definition of «work»? If the 
> resource is rendered in a browser widget, is it good enough to give 
> the fragment focus, or should the fragment be extracted from the 
> source and then served to the widget? What if the resource is not 
> rendered in a browser widget or not rendered at all?

Asjbjørn, please consult http://www.w3.org/TR/webarch on the issues 
around fragment identifiers. There's no such thing as xml:id, and the 
semantics of #fragid are mime-type specific, and thus you can't expect 
software to do anything reasonable with one unless it knows about that 
mime type.  Yes, the whole thing is kind of kludgy, but ruling out 
#fragid's would be too painful. -Tim

---

From: [email-masked]
Date: Mon, 06 Sep 2004 04:21:43 -0700 (PDT)

> but if sent by mail, what Tim cites below applies.

My point was and is that different choices can be made in different
protocols, but when this is done the effect on interoperability needs
to be considered. Whether or not ATOM actually wants to do this
is something for the WG to decide.

				Ned

---

From: Janne Jalkanen <[email-masked]>
Date: Mon, 06 Sep 2004 17:18:34 +0300

>whatsoever, then use markup.
-1

With Wikis, whitespace can actually be significant.  Forbidding line 
breaks may make it difficult, or even impossible to edit a WikiPage.

I would not like to require an XHTML parser in order for a Wiki to 
support Atom.  (However, in general, I think every wiki *should* be able 
to import XHTML... :)

/Janne

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 11:59:57 -0400

> I strongly recommend that ATOM consider aligning with this mechanism.

Looking at RFC 2646, and in particular, section 3.1, it appears that 
there is quite some diversity in how text/plain is interpreted in 
various clients.  Fonts may be proportional-spaced or fixed.  Line 
breaks may be hard or soft.  Text may be fixed for flowed.

Looking at how titles are handled in tools like Bloglines, what starts 
out as

   <title>title</title>

Becomes something like

   <h3><a href="alternate">title</a></h3>

Experimenting with IE6 and Mozilla 1.7.2, it seems that all line breaks 
in such constructs are treated as "soft", all text is flowed (including 
lines starting with &lt;).

However we specify this (either with an existing media type, or with an 
alternative mechanism that "replace one set of problems with 
another"[1]), it seems to me that we don't want to spec anything which 
will preclude the behavior above.

- Sam Ruby

[1] http://www.imc.org/atom-syntax/mail-archive/msg09566.html

---

From: Ken MacLeod <[email-masked]>
Date: 07 Sep 2004 10:53:58 -0500

Janne Jalkanen <[email-masked]> writes:

> support Atom.  (However, in general, I think every wiki *should* be
> able to import XHTML... :)

There are two assumptions here that should be considered:

 1) <content> is the right element for submitting, syndicating, or
    archiving the unprocessed user input (whether it be X/HTML or wiki
    markup).  A new element, <input> or <raw-content>, might be more
    suitable.

 2) text/plain is the right media type for Wiki markup.  The
    specification of text/plain[1] excludes markup of any kind:

        [text/plain] indicates plain text that does not contain any
        formatting commands or directives. Plain text is intended to
        be displayed "as-is", that is, no interpretation of embedded
        formatting commands, font attribute specifications, processing
        instructions, interpretation directives, or content markup
        should be necessary for proper display.

    There is work in progress to register a text/wiki media type, but
    it needs help to avoid being tied to one particular markup style
    (tiki).

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 12:06:25 -0400

While I am in overall agreement with the approach this takes, I'm 
troubled by a minor detail: namely that the default for type varies from 
element to element.

My preference is that the default for content be made consistent with 
the text constructs.  My motivation is that I don't want to see markup 
ever being accidental, I would much prefer that is something that always 
is explicit.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Mon, 06 Sep 2004 10:26:47 -0700

On Sep 6, 2004, at 9:06 AM, Sam Ruby wrote:

> troubled by a minor detail: namely that the default for type varies 
> from element to element.
>
> ever being accidental, I would much prefer that is something that 
> always is explicit.

I think Sam's probably right.  Simpler is better.  So, let's figure out 
what the default is.

Strawman position: text/html.  It turns out that text/plain is a little 
less obvious than we'd thought, and I suspect most people, most times, 
would rather have their text flowed and rendered in a proportional 
font.  Downside: double-escaping.  Anyone got a Plan B? -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 15:41:39 -0400

> font.  Downside: double-escaping.  Anyone got a Plan B? -Tim

I definately think that this is the wrong default for titles.

Per my reading of RFC 2646, it is explicitly recognized that text/plain 
may be flowed and may be rendered in a proportional font.

However, iIf we feel that text/plain is problematic, then IMHO, it 
should be removed from the Pace, in which case I feel that 
PaceSimpleContentType got the default right: namely flowed, 
proportional, and single escaping.  The only downside is that it allows, 
by default, mixed content.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 06 Sep 2004 23:11:05 +0200

On Sun, 05 Sep 2004 23:25:54 -0700, Tim Bray <[email-masked]> wrote:

> around fragment identifiers.

All of them apply to atom:content/@src?

> There's no such thing as xml:id

Huh? <url: http://www.w3.org/TR/xml-id/>

> and the semantics of #fragid are mime-type specific, and thus you can't
> expect software to do anything reasonable with one unless it knows about
> that mime type.

Okay, that's basically what I wanted to know.

> Yes, the whole thing is kind of kludgy, but ruling out #fragid's would
> be too painful.

I'm not critizising fragment identifiers, I'm just wondering how they are  
supposed to be handled, that's all.

---

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

On Sep 6, 2004, at 12:41 PM, Sam Ruby wrote:

> proportional, and single escaping.  The only downside is that it 
> allows, by default, mixed content.

Removing text/plain feels controversial, although I agree we need to be 
a little more clear about what it means.

As for the second part: "flowed, proportional, and single escaping".  
Sounds like type="application/xhtml+xml" to me.  The more I think about 
this, the more I like xhtml as a default.  If you want a <br/> in your 
title, just put it in, like that.  If you want to say "vi < emacs", 
just say "vi &lt; emacs".  If you want to copy in someone else's HTML 
and you're not sure it's going to be well-formed, say type="text/html". 
  Is there a downside?

  -Tim

---

From: Sam Ruby <[email-masked]>
Date: Mon, 06 Sep 2004 20:11:11 -0400

Tim Bray wrote:
> title, just put it in, like that.  If you want to say "vi < emacs", just 
> say "vi &lt; emacs".  If you want to copy in someone else's HTML and 
> you're not sure it's going to be well-formed, say type="text/html".  Is 
> there a downside?

Typically the <br/> would be in the wrong namespace.  To address this, 
PaceSimpleContentType specifies:

   To use XHTML 1.0 content, the Content construct MUST contain only
   one child element and that element MUST be in the XHTML namespace
   'http://www.w3.org/1999/xhtml'.

Overall, I would still like to see some mechanism for plain text be made 
to work, and made the default.  If not, I would like to see some 
combination of PaceSimpleContentType and PaceReformedContent.

- Sam Ruby

---

From: Tim Bray <[email-masked]>
Date: Tue, 07 Sep 2004 22:34:33 -0700

On Sep 6, 2004, at 5:11 PM, Sam Ruby wrote:

> Overall, I would still like to see some mechanism for plain text be 
> made to work, and made the default.  If not, I would like to see some 

What you say sounds sensible.  I'm on the road this week.  Feel like 
doing a PaceReformedContent2?  -Tim