Subject: Difference of TEXT and XHTML?

From: Henri Sivonen <[email-masked]>
Date: Wed, 26 Jan 2005 22:44:03 +0200

Quoting from draft-ietf-atompub-format-04:

> 3.1.1  "type" Attribute
...
>    If the value is "TEXT", the content of the Text construct MUST NOT
>    contain child elements.  Such text is intended to be presented to
>    humans in a readable fashion.  Thus, software MAY display it using
>    normal text rendering techniques such as proportional fonts,
>    white-space collapsing, and justification.
...
>    If the value of "type" is "XHTML", the content of the Text construct
>    MAY contain child elements.  The content SHOULD be XHTML text and
>    markup that could validly appear directly within an xhtml:div
>    element.  Receiving software which displays the content MAY use the
>    markup to aid in displaying it.

Considering that TEXT MAY be white-space collapsed (why not SHOULD?) 
and XHTML allows anything that could go in div including text, isn't 
TEXT redundant?

What's the difference between:
<atom:title type='TEXT'>I   do not like 
<![CDATA[<]]>marquee&gt;</atom:title>
and
<atom:title type='XHTML'>I   do not like 
<![CDATA[<]]>marquee&gt;</atom:title>
?

Shouldn't both render as "I do not like <marquee>"?

FWIW, with the exception of content, I think allowing only %inline 
XHTML elements would make more sense than allowing %flow.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 13:18:17 -0800

> Shouldn't both render as "I do not like <marquee>"?

Yeah, but if you wanted to have 'not' in bold:

<title type='TEXT'>I do not like &lt;marquee></title> (can't do it)
<title type='HTML'>I do &lt;b>not&lt;/b> like &amp;lt;marquee></title>
<title type='XHTML'>I do <b>not</b> like &lt;marquee></title>

(Hey, an example like that might be helpful in the spec.)

> XHTML elements would make more sense than allowing %flow.

Anyone else pro or con on this one? -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 26 Jan 2005 14:34:57 -0700

> <title type='XHTML'>I do <b>not</b> like &lt;marquee></title>
The last one needs to be something like the following, right?

<title type='XHTML'><div xmlns="http://www.w3.org/1999/xhtml">I do 
<b>not</b> like &lt;marquee></div></title>

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 26 Jan 2005 23:31:24 +0200

> <title type='XHTML'>I do <b>not</b> like &lt;marquee></title>

But if you can always substitute type='TEXT' with type='XHTML' but not 
the other way round, what's the point of having type='TEXT' in the 
spec?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Lucas Gonze <[email-masked]>
Date: Wed, 26 Jan 2005 11:40:13 -1000 (HST)

>> FWIW, with the exception of content, I think allowing only %inline XHTML 
>> elements would make more sense than allowing %flow.

> Anyone else pro or con on this one? -Tim

This has elegance and is intuitively appealing.  However it would open up 
a can of worms with styling.

CSS must go in the document head.  Inline HTML or XHTML probably doesn't 
have access to the document head.  XHTML doesn't have styling elements 
like <font>, HTML does.  So there would have to be a provision to get CSS 
into the document head, which adds complexity instead of subtracting it.

One thing -- my knowledge of XHTML is shallow, so I may be missing a 
solution to styling that doesn't require HTML.

- Lucas Gonze

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 13:46:19 -0800

> the other way round, what's the point of having type='TEXT' in the 

With type='TEXT' you know it's not going to contain any (X)HTML 
formatting, so you don't have to invoke your (X)HTML renderer. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Wed, 26 Jan 2005 16:53:39 -0500

Henri Sivonen wrote:

> the other way round, what's the point of having type='TEXT' in the spec?

You can't.

<title 
type='TEXT'>I&amp;nbsp;do&amp;nbsp;not&amp;nbsp;like&amp;nbsp;&lt;marquee></title>
<title type='TEXT'>I    do     not      like      ...</title>

Robert Sayre

---

From: PA <[email-masked]>
Date: Wed, 26 Jan 2005 23:02:33 +0100

> formatting, so you don't have to invoke your (X)HTML renderer. -Tim

Newbie question:

Why is "type" not a MIME type already? As in an anchor tag for example?

http://www.w3.org/TR/REC-html40/struct/links.html#adef-type-A

I'm sure there must be a very valid reason for such unfortunate 
discrepancy, but at first glance I cannot see it:

3.1.1  "type" Attribute

    Note that MIME media types [RFC2045] are not acceptable values for
    the "type" attribute.

3.5.2  "type" Attribute

    Link constructs MAY have a type attribute, whose value MUST conform
    to the syntax of a MIME media type [RFC2045].

Cheers

--
PA
http://alt.textdrive.com/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 00:24:38 +0200

On Jan 26, 2005, at 23:53, Robert Sayre wrote:

> Henri Sivonen wrote:
>
>> But if you can always substitute type='TEXT' with type='XHTML' but  
>> not the other way round, what's the point of having type='TEXT' in  
>> the spec?
>
>
> You can't.
>
> <title  

Sorry, I don't understand what your example is demonstrating.

How would the above be different from:
<title  
type='XHTML'>I&amp;nbsp;do&amp;nbsp;not&amp;nbsp;like&amp;nbsp;&lt; 
marquee></title>
<title type='XHTML'>I    do     not      like      ...</title>
?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 00:38:12 +0200

On Jan 26, 2005, at 23:46, Tim Bray wrote:

> formatting, so you don't have to invoke your (X)HTML renderer.

Is it useful to support that kind of optimization on the format level? 
I would expect a feed renderer to use the same rendering approach for 
all titles for visual consistency. Even if a renderer chose to make 
optimizations, surely it could check for element children itself (which 
would be more robust than trusting the feed generator).

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 00:42:55 +0200

On Jan 26, 2005, at 23:40, Lucas Gonze wrote:

> Inline HTML or XHTML probably doesn't have access to the document head.

Neither has %flow.

> XHTML doesn't have styling elements like <font>, HTML does.

Both XHTML 1.0 Transitional and HTML 4.01 Transitional have <font>. 
Neither XHTML 1.0 Strict nor HTML 4.01 Strict has <font>.

> So there would have to be a provision to get CSS into the document 
> head, which adds complexity instead of subtracting it.

Why would there have to be a method for shipping CSS for titles and 
similar "text constructs"?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Robert Sayre <[email-masked]>
Date: Wed, 26 Jan 2005 17:45:16 -0500

> <title type='XHTML'>I    do     not      like      ...</title> 

Oop, sorry. I pasted the first example in from one of the other times 
this has cropped up.

Well I'll be damned. The spec says whitespace collapsing is allowed.

But guess what, "TEXT" is *never* coming out of the spec, because it 
will eventually become impossible to write something that looks like 
markup if we don't have it. If we were to choose between the two, we 
should eliminate XHTML.

Robert Sayre

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 00:55:08 +0200

On Jan 27, 2005, at 00:45, Robert Sayre wrote:

> markup if we don't have it.

How so? What does type='TEXT' make possible to write that type='XHTML' 
with a single text node does not make possible to write?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 10:48:10 +1100

> <title type='XHTML'>I    do     not      like      ...</title>

try instead this example "I <3 Huckabees"...

e.

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 21:40:28 -0500

Henri Sivonen wrote:
> Is it useful to support that kind of optimization on the format level? I 
> would expect a feed renderer to use the same rendering approach for all 
> titles for visual consistency. Even if a renderer chose to make 

I'm not so concerned about the optimization.  But having observed quite 
a number of people tripping over double escaping rules in various 
flavors of RSS, I very much like having a very conservative default of 
TEXT.  And then for those who wish to get more adventurous, there are 
two choices: XHTML (compact, clear, but must be well formed), and double 
escaped HTML (verbose, error prone, but can handle arbitrary content).

- Sam Ruby

---

From: Lucas Gonze <[email-masked]>
Date: Wed, 26 Jan 2005 17:03:09 -1000 (HST)

On Thu, 27 Jan 2005, Henri Sivonen wrote:
> Both XHTML 1.0 Transitional and HTML 4.01 Transitional have <font>. Neither 
> XHTML 1.0 Strict nor HTML 4.01 Strict has <font>.

Then my point is moot as long as XHTML inline content may be XHTML 1.0 
Transitional.  A second argument that inline XHTML may be XHTML 1.0 
Transitional is that it satisfies the need for well-formed XML.

>> So there would have to be a provision to get CSS into the document head, 
>> which adds complexity instead of subtracting it.
>
> Why would there have to be a method for shipping CSS for titles and similar 
> "text constructs"?

Because having control over presentation is the main reason to format 
content as HTML.

- Lucas Gonze

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 27 Jan 2005 07:41:18 +0100

> <b>not</b> like &lt;marquee></div></title>

I was wondering about this as well. When you have @type['XHTML'], does 
it need to be in a namespace, or not? (Sounds logical, but apparently 
people do different things.)

And which XHTML DTD has to be followed for the content model?

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 09:14:32 +0200

> try instead this example "I <3 Huckabees"...

That makes no difference, either.

<title type='TEXT>I &lt;3 Huckabees</title>
<title type='XHTML>I &lt;3 Huckabees</title>

Only type='HTML' is different.
<title type='HTML>I &lt;lt;3 Huckabees</title>

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 09:23:01 +0200

On Jan 27, 2005, at 04:40, Sam Ruby wrote:

>  But having observed quite a number of people tripping over double 
> escaping rules in various flavors of RSS, I very much like having a 
> very conservative default of TEXT.  And then for those who wish to get 
> more adventurous, there are two choices: XHTML (compact, clear, but 
> must be well formed), and double escaped HTML (verbose, error prone, 
> but can handle arbitrary content).

But type='TEXT' is only a degenerate case of type='XHTML' (type='XHTML' 
with only text content). What value does type='TEXT' add to the format 
except the ability of feedvalidator.org to detect cases where there are 
element children although the author claims there are not, which 
suggests an authoring error? Does type='TEXT' intentionally exist only 
to add this feedvalidator.org value?

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 09:31:34 +0200

>> <b>not</b> like &lt;marquee></div></title>

Or, rather:
<title type='XHTML'>I do <b 
xmlns="http://www.w3.org/1999/xhtml">not</b> like &lt;marquee></title>

> people do different things.)

Why wouldn't it require the elements that purport to be XHTML elements 
to be in the XHTML namespace? I do not, however, think that it is 
useful to restrict type='XHTML' in the content element to have element 
descendants only from the XHTML namespace. Those who want to do math 
will mix MathML with XHTML anyway and have it render in a future 
non-bogotic feed reader Firefox extension (which I expect someone to 
write sooner or later).

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Tim Bray <[email-masked]>
Date: Wed, 26 Jan 2005 23:41:39 -0800

On Jan 26, 2005, at 11:23 PM, Henri Sivonen wrote:

> But type='TEXT' is only a degenerate case of type='XHTML' 
> (type='XHTML' with only text content). What value does type='TEXT' add 
> to the format except the ability of feedvalidator.org to detect cases 
> where there are element children although the author claims there are 
> not, which suggests an authoring error? Does type='TEXT' intentionally 
> exist only to add this feedvalidator.org value?

OK, you've advanced this argument several times now.  If you want to 
change the Atom format to remove type="TEXT", write a Pace (it'll be 
short & easy) and see if you can build consensus.

I have to warn you that the process by which we got to consensus on the 
current setup was long, arduous, and involved a huge volume of email, 
and you may get -1's based on people just not wanting to revisit this 
space. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 18:42:11 +1100

> <title type='HTML>I &lt;lt;3 Huckabees</title>

is that right for XHTML?

after XML decoding, the string data would be "I <3 Huckabees", which if
directly embedded into an XHTML <div> would be broken...

    <xhtml>
    <head></head>
    <body><div>I <3 Huckabees</div></body>
    </xhtml>

what am I missing?

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 27 Jan 2005 08:46:45 +0100

> Transitional is that it satisfies the need for well-formed XML.

You do whatever you please, of course, but HTML and XHTML is not supposed  
to be used for formatting, but for structure and semantics. That's why  
<font> et al has been dropped from XHTML 1.1, 2.0 and the Strict DTD's  
(which is recommended to use over the Transitional ones).

> Because having control over presentation is the main reason to format  

Uhm. Okay.

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

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 18:47:50 +1100

> to add this feedvalidator.org value?

maybe it exists so I can write a title which looks like this

    "I hate the <blink> tag"

which is the plain text rendition, or if I wanted to code it in html/xhtml
it would be 

    "I hate the &lt;blink&gt; tag"

and then applying XML escaping ... would be the following? ...

    <title type='TEXT >I hate the &lt;blink&lt; tag</title>
    <title type='HTML >I hate the &amp;lt;blink&amp;&lt; tag</title>
    <title type='XHTML>I hate the &amp;lt;blink&amp;&lt; tag</title>

e.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 14:22:22 +0200

>> <title type='HTML>I &lt;lt;3 Huckabees</title>

Doh. That should have been
<title type='HTML>I &amp;lt;3 Huckabees</title>

> is that right for XHTML?

Yes.

>     <body><div>I <3 Huckabees</div></body>

You try to concatenate the parsed text node content string to a 
skeleton source string instead of moving the parsed text node to 
skeleton tree.

When <title type='XHTML>I &lt;3 Huckabees</title> is parsed, you get a 
'title' element node with a text node child whose content is "I <3 
Huckabees". To form an XHTML document, you don't concatenate that 
string to some source markup, but you move the text node to a tree like 
this (assume XHTML namespace):
html
   head
   body
     div
       #text: "I <3 Huckabees"

If this tree is now serialized, we get
<html xmlns='http://www.w3.org/1999/xhtml'><head/><body><div>I &lt;3 
Huckabees</div></body></html>

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Eric Scheid <[email-masked]>
Date: Thu, 27 Jan 2005 23:46:08 +1100

> Huckabees</div></body></html>

ahhhm ... ok, sounds reasonable.

however, the spec says:

    The content SHOULD be XHTML text and markup that could
    validly appear directly within an xhtml:div element.

which could lead others to make the same mistake I must have made.

e.

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 15:21:19 +0200

> short & easy) and see if you can build consensus.

http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant

> I have to warn you that the process by which we got to consensus on 
> the current setup was long, arduous, and involved a huge volume of 
> email, and you may get -1's based on people just not wanting to 
> revisit this space.

Sure, the current version is better than the mode/type stuff.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Sam Ruby <[email-masked]>
Date: Thu, 27 Jan 2005 08:34:36 -0500

> http://www.intertwingly.net/wiki/pie/PaceTypeTextRedundant

There are cases where explicit is better than implicit.

The default for title should be TEXT - i.e., no markup.

Those that wish to add markup should be required to be explicit about 
it.  Particularly, as this has proven to be a very error prone process.

Allowing the declaration of markup to be implicit (i.e., having a 
default for type) will lead to continued confusion and errors.

I am -1 on this Pace.  Making type required on all textual elements 
would address my concern, but my preference is to leave the spec as it is.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Thu, 27 Jan 2005 14:48:44 +0000

> There are cases where explicit is better than implicit.

Yes. It's more a psychological rather than a technical difference, but 
I think it's important (it's like the difference between ASCII and 
UTF-8).

-1 on the pace.

Graham

(PS Are line breaks in Text mode honored?)

---

From: Danny Ayers <[email-masked]>
Date: Thu, 27 Jan 2005 16:14:00 +0100

I only noticed this thread after looking at the same material through
RDF-tinted spectacles.

A question for the schema mavens: is there *any* clear way of
describing the difference between the three content types
(TEXT/HTML/XHTML) in a machine readable fashion?

In the Rosy-tinted Description Framework, if the type could be fully
expressed using XML Schema datatypes, the Atom content element could
map nicely onto a XSD-datatyped literal. Problem is I couldn't see any
obvious way of distinguishing HTML from TEXT, as the former would be
escaped anyway.

So in effect for RDF I think the content would have to appear as a
literal, with the type as a kind of annotation, the easiest RDF/XML
version being something like:

<atom:contentConstruct>
  <atom:content>yodel-ay-ey-oo</atom:content>
  <atom:datatype>TEXT</atom:datatype>
</atom:contentConstruct>

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Thu, 27 Jan 2005 07:50:51 -0800

> which could lead others to make the same mistake I must have made.

The easiest way to solve this, I think, is with examples. -Tim

---

From: Robert Sayre <[email-masked]>
Date: Thu, 27 Jan 2005 11:45:01 -0500

> I think it's important (it's like the difference between ASCII and 

-1 as well. Allowing people to assert they are using a subset of what's 
available is not a design error.

> (PS Are line breaks in Text mode honored?)

The current text says whitespace collapsing is allowed.

Robert Sayre

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 18:55:00 +0200

> (PS Are line breaks in Text mode honored?)

The current spec text allows (IMO, it would be better to require) 
white-space normalization, so no line breaks are not honored.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 18:58:07 +0200

On Jan 27, 2005, at 17:50, Tim Bray wrote:

> The easiest way to solve this, I think, is with examples.

Avoiding the word "markup" would also help avoiding any associations 
with unparsed source.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 19:01:00 +0200

> obvious way of distinguishing HTML from TEXT, as the former would be

As a practical solution, you could use a SAX filter for converting HTML 
and TEXT to XHTML and then deal with only XHTML in the RDF mapping.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 10:00:11 -0700

On Thursday, January 27, 2005, at 12:47  AM, Eric Scheid wrote:
>> (type='XHTML'
In a message sent off-list to me last June, which I no longer have, but 
referred to in a message on list[1], Sam said that:

	<content type="inline-xhtml">
		&amp;copy;
	</content>

should be rendered "&copy;", not as a copyright symbol (because it's 
not in the XHTML namespace, ie. it's not this:)

	<content type="inline-xhtml">
		<span xmlns="http://www.w3.org/1999/xhtml">&amp;copy;</span>
	</content>

...which seems to suggest that the above XHTML example should be:

	<title type="XHTML">I hate the &lt;blink&gt; tag</title>

or:

	<title type="XHTML"><span xmlns="http://www.w3.org/1999/xhtml">I hate 
the &amp;lt;blink&amp;&gt; tag</span></title>

...of course, it's difficult to say whether applications actually WOULD 
do it that way, or whether they'd treat the text as if it were in the 
XHTML namespace based on the @type value.  Getting rid of @type="TEXT" 
could lead to a situation similar to RSS 2.0 where content that is 
intended to be rendered as plain text was being treated as markup.  If 
people use @type="XHTML" without a namespace for content intended to be 
rendered as plain text, they'll still have this problem, but if they 
have the option of @type="TEXT", they'll have an unambiguous way to do 
it without having to add gratuitous markup.

Thus, -1 on PaceTypeTextRedundant.

Antone

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

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 10:30:30 -0700

Given how common it is even for us, when posting examples of <content 
type="XHTML"> without declaring the XHTML namespace, might it be a good 
idea to specify a mandatory method of declaring the XHTML namespace to 
ensure that implementors don't forget?  I realize that it could be done 
multiple ways, but would there be any drawback to mandating one?  I'd 
suggest changing:

    If the value of "type" is "XHTML", the content of the Text construct
    MAY contain child elements.  The content SHOULD be XHTML text and
    markup that could validly appear directly within an xhtml:div
    element.  Receiving software which displays the content MAY use the
    markup to aid in displaying it.  Escaped markup is interpreted as a
    text representation of markup, and MUST NOT be interpreted as markup
    itself.

to something like:

If the value of "type" is "XHTML", the content of the Text construct 
MUST be a single xhtml:div element which MUST declare the XHTML 
namespace, either as the default namespace or with a namespace prefix 
[[[we COULD require it to be the default namespace--any drawbacks to 
that?]]].  The xhtml:div element MAY contain child elements.   
Receiving software which displays the content MAY use any markup to aid 
in displaying it.  Escaped markup is interpreted as a text 
representation of markup, and MUST NOT be interpreted as markup itself.

Examples:

<content type="XHTML"><div xmlns="http://www.w3.org/1999/xhtml">The 
word <b>bold</b> is bold.</div></content>

<content type="XHTML"><div 
xmlns:xhtml="http://www.w3.org/1999/xhtml">The word 
<xhtml:b>bold</xhtml:b> is bold.</div></content>

<content type="XHTML"><div xmlns="http://www.w3.org/1999/xhtml" 
style="color:#03c;">The word <b>bold</b> is bold.</div></content>

If I get no explanations of why this is a bad idea, I'll write a Pace.

Antone

---

From: Sam Ruby <[email-masked]>
Date: Thu, 27 Jan 2005 12:30:16 -0500

Antone Roundy wrote:
> should be rendered "&copy;", not as a copyright symbol (because it's not 
> in the XHTML namespace, ie. it's not this:)

I did say that that's how it should be rendered (I forwarded to you my 
original email) but the reason has nothing to do with namespaces.

>     <title type="XHTML">I hate the &lt;blink&gt; tag</title>

yes

> or:
> 
>     <title type="XHTML"><span xmlns="http://www.w3.org/1999/xhtml">I 
> hate the &amp;lt;blink&amp;&gt; tag</span></title>

no

Clearly some examples ARE in order.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 10:46:35 -0700

On Thursday, January 27, 2005, at 10:30  AM, Sam Ruby wrote:
>> In a message sent off-list to me last June, which I no longer have, 
>> but referred to in a message on list[1], Sam said that:
Recent reading, including this response, is leading me to believe that 
I'd misunderstood @type="XHTML".  Questions:

1) Clearly, this cannot appear in an Atom feed, because &copy; is not 
an XML entity:

	<content type="XHTML">&copy;</content>

What about this?

	<content type="XHTML"><div 
xmlns="http://www.w3.org/1999/xhtml">&copy;</div></content>

2) If that is valid (I'm presuming that it is, and that it should be 
rendered as a copyright symbol), I'm wondering how many XML parsers are 
going to choke on it anyway.  If that is NOT valid, then how would one 
put a copyright symbol (or any other XHTML entity that is not an XML 
entity) into XHTML content in an Atom feed?

> Clearly some examples ARE in order.
Yep.  And if many XML parsers are going to choke on the above example, 
warnings too.

Antone

---

From: Robert Sayre <[email-masked]>
Date: Thu, 27 Jan 2005 12:40:34 -0500

> If I get no explanations of why this is a bad idea, I'll write a Pace.

Every XHTML feed I've seen in the wild starts with a single div element +1.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Thu, 27 Jan 2005 13:04:37 -0500

Antone Roundy wrote:

> 1) Clearly, this cannot appear in an Atom feed, because &copy; is not an 
> XML entity:
> 

Neither are well formed XML.  Invoking a namespace does not implicitly 
provide you with additional entities.  Using the XHTML DTD (not 
recommended in this case) woulld.

> entity) into XHTML content in an Atom feed?

By definition, all XML parsers will choke on the latter.  If not, they 
are not conformant.

- Sam Ruby

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 27 Jan 2005 19:36:15 +0100

>xmlns="http://www.w3.org/1999/xhtml">&copy;</div></content>

That depends on whether the document has a document type declaration and
if how it looks like. And on various properties of the XML processor and
the application using it, as well as on various dynamic conditions. E.g.
whether the document type declaration refers to an external subset and
whether the processor attempts to resolve the reference. If there is no
document type declaration, the document would not be well-formed.

>entity) into XHTML content in an Atom feed?

There are two ways to refer to such characters, either by literally in-
cluding them (in very much the same way as you've included "X" and "L"
in your example) or by using character references ala

  <content type="&#x58;HTML"><div ...
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Tim Bray <[email-masked]>
Date: Thu, 27 Jan 2005 10:36:29 -0800

On Jan 27, 2005, at 9:30 AM, Antone Roundy wrote:

> Receiving software which displays the content MAY use any markup to 
> aid in displaying it.  Escaped markup is interpreted as a text 

I'd probably be +1 on that.  No, it would be way out of bounds-bad XML 
practice-to talk about whether it's the default namespace or some 
explicit namespace.  -Tim

---

From: Antone Roundy <[email-masked]>
Date: Thu, 27 Jan 2005 11:36:35 -0700

On Thursday, January 27, 2005, at 11:04  AM, Sam Ruby wrote:
>> Recent reading, including this response, is leading me to believe 
>> that I'd misunderstood @type="XHTML".  Questions:

Ah yes, of course.  It's amazing how obvious things can be the instant 
they're explained even slightly.

So, what limitations are we running into with @type="XHTML"?

1) Can't use non-XML entities.
2) Can't use CSS classes and IDs--this is true of @type="HTML" too, of 
course.

Any others?  Any solutions?  Do we WANT to solve these?  Not in version 
1.0?

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 27 Jan 2005 22:39:49 +0200

On Jan 27, 2005, at 19:30, Antone Roundy wrote:

> type="XHTML"> without declaring the XHTML namespace, might it be a 
> good idea to specify a mandatory method of declaring the XHTML 
> namespace to ensure that implementors don't forget?

+1 That should be obvious.

> MUST be a single xhtml:div element

-1 gratuitous element cruft. The text construct element itself serves 
as a container.

> which MUST declare the XHTML namespace, either as the default 
> namespace or with a namespace prefix

-1 Atom should not micro-manage how and on which elements namespace 
declarations appear.

Feed in the wild that declares the namespaces on root:
http://macsanomat.fi/atom

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Tim Bray <[email-masked]>
Date: Thu, 27 Jan 2005 13:00:35 -0800

> http://macsanomat.fi/atom

He's got a point.  It's a common (and many people say, good) idiom to 
declare all your namespaces on your root.  I think all we can/should 
really say is that when type="XHTML", it is the responsibility of the 
feed generator to declare the XHTML namespace, because Atom won't do it 
for you. -Tim

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Jan 2005 22:11:50 +0100

> feed generator to declare the XHTML namespace, because Atom won't do it 

+1

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 10:38:45 +1100

> -1 gratuitous element cruft. The text construct element itself serves

but atom:title != xhtml:title

also, are there such things as xhtml:copyright, xhtml:info, or
xhtml:summary?

> Feed in the wild that declares the namespaces on root:

Good point. The declaration of the namespace 'xhtml' can occur elsewhere,
and if on the root then it cuts down on needless repetition.

e.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 28 Jan 2005 11:57:51 +0900

declarations appear.
 >He's got a point.  It's a common (and many people say, good) idiom to 
declare all your namespaces on your root.  I think all we can/should really 
say is that when type="XHTML", it is the responsibility of the feed 
generator to declare the XHTML namespace, because Atom won't do it for you. -Tim

+1 on this, -1 on any additional suggestions in this thread.
We are using XML with namespaces, and we shouldn't mess
around with that.

Regards,    Martin.

---

From: Eric Scheid <[email-masked]>
Date: Fri, 28 Jan 2005 17:59:40 +1100

On 28/1/05 4:58 PM, "Henri Sivonen" <[email-masked]> wrote:

> <a:copyright type='XHTML'>Copyright 2005 John Doe, <h:em>all rights
> reserved</h:em></a:copyright>
> (assuming 'a' to be bound to the Atom namespace and 'h' to the XHTML
> namespace) is less crufty than
> <a:copyright type='XHTML'><div
> xmlns='http://www.w3.org/1999/xhtml'>Copyright 2005 John Doe, <em>all
> rights reserved</em></div></a:copyright>

and this is somewhere in the middle...

    <a:copyright type='XHTML'>
        <h:div>Copyright 2005 John Doe, <em>all rights reserved</em></h:div>
    </a:copyright>

once you have more than just one set of tags like <em></em> in there.

e.

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 28 Jan 2005 07:58:07 +0200

> also, are there such things as xhtml:copyright, xhtml:info, or

No, but that is not the point. The *Atom* Text constructs work as 
containers. The div is just cruft.

IMO,
.

Even if you wanted to declare the XHTML namespace on the spot, you 
could put the declaration on the Atom Text construct. Any feed reader 
using namespace-aware XML tools properly will have no trouble dealing 
with the less crufty versions.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 28 Jan 2005 12:30:20 +0200

> once you have more than just one set of tags like <em></em> in there.

The em element does not inherit the namespace of he div. You could have 
  bound to one namespace, 'h' to another and still have a third 
namespace as the default namespace.

It would be inapropriate to forbit declaring the same namespace in 
multiple ways, but the div is still cruft and unnecessary for declaring 
namespaces, so I think the div shouldn't be required.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 05:55:49 +0100

> namespaces, so I think the div shouldn't be required.

I kind of agree. We should state that the child elements of atom:content  
must be namespace qualified and within another namespace than Atom, but  
how people would like to accomplish this restriction is up to them, imho.