Subject: How should this be rendered?

From: Graham <[email-masked]>
Date: Sat, 16 Apr 2005 16:50:10 +0100

Adapted from a BBC feed I was playing with:

<content type="text">ARCHAEOLOGY AND IMPERIALISM

In 1842 a young English adventurer called Austen Henry Layard set out 
to excavate what he hoped were the remains of the biblical city of 
Nineveh in Mesopotamia. On arrival he discovered that the local French 
consul, Paul Emile Botta, was already hard at work. Across the Middle 
East and in Egypt, archaeologists, antiquarians and adventurers were 
exploring cities older than the Bible and shipping spectacular 
monuments down the Nile and the Tigris to burgeoning European museums.

What was it about the ancient cultures of Egypt and Mesopotamia that so 
gripped the 19th century imagination? How did nationalism and 
imperialism affect the search for the ancient past and how did 
archaeology evolve from its adventuresome, even reckless, origins into 
the science of artefacts we know today?

Contributors: Tim Champion, Professor of Archaeology at the University 
of Southampton, Richard Parkinson, Assistant Keeper in the Department 
of Ancient Egypt and Sudan at the British Museum, Eleanor Robson, 
Lecturer in the History and Philosophy of Science at Cambridge 
University and a Fellow of All Souls College, Oxford

Making this MP3 available is an experiment. We value your thoughts 
about this trial, and would appreciate feedback at: 
http://www.bbc.co.uk/radio4/history/inourtime/mp3.shtml#feedback
</content>

====

Should the line breaks be shown to the user? Please quote spec text to 
back up your answers.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Sun, 17 Apr 2005 05:03:37 +1000

> Should the line breaks be shown to the user? Please quote spec text to

wouldn't that depend on what the end application is, and how it displays
text/plain?

my email client displays text/plain with line breaks, my various browsers do
too, my hex editor doesn't.

e.

---

From: Graham <[email-masked]>
Date: Sat, 16 Apr 2005 20:25:46 +0100

> too, my hex editor doesn't.

So your saying under normal circumstances a client should display the 
line breaks? Seeing as I've been told before that the spec clearly says 
they shouldn't, I think we have a problem.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sat, 16 Apr 2005 15:33:45 -0400

> they shouldn't, I think we have a problem.

"Atom Processors MAY display it using normal text rendering techniques 
such as proportional fonts, white-space collapsing, and justification."

MAY or MAY NOT. There's no right answer in there right now.

Robert Sayre

---

From: "A. Pagaltzis" <[email-masked]>
Date: Sun, 17 Apr 2005 01:02:26 +0200

* Robert Sayre <[email-masked]> [2005-04-16 21:45]:
> "Atom Processors MAY display it using normal text rendering
> techniques such as proportional fonts, white-space collapsing,
> and justification."
> 

Would @xml:space be applicable if I as a producer want to be
certain of a way of interpreting my content? Say, because I’m
putting ASCII art in there?

Regards,
-- 
Aristotle

---

From: Graham <[email-masked]>
Date: Mon, 18 Apr 2005 18:52:05 +0100

> putting ASCII art in there?

No, since xml:space isn't a built-in part of XML, and isn't referenced 
by the atom spec. It can only be used when spec-makers (us) say it can.

Graham Parks

---

From: Graham <[email-masked]>
Date: Mon, 18 Apr 2005 19:00:40 +0100

> MAY or MAY NOT. There's no right answer in there right now.

I'm OK with line-breaks being ignored, because it means documents where 
the XML has been wrapped to 80 columns aren't messed up.

I'm not OK with publishers not being clear on the situation. Would 
anyone object to "(including line-breaks)" being added after 
"white-space collapsing":

I'd also like to remove the word "normal" from there, since these 
aren't normal for text/plain, which is the obvious analogy.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 18 Apr 2005 14:01:13 -0400

> by the atom spec. It can only be used when spec-makers (us) say it can.

People can put it in there, per section 6.4, but no one has to pay 
attention.

Let's examine our rules for HTML content. There's no requirement to use 
the markup to display the content, so it would be perfectly cool to drop 
a <br>.

Is there a specific outcome you're looking for here?

Robert Sayre

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 18 Apr 2005 20:08:30 +0200

Graham wrote:
> No, since xml:space isn't a built-in part of XML,

Duh! Why then is it described in 
http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space

> and isn't referenced 

...and I think it should be allowed on text constructs and atom:content.

How are you supposed to write an HTML PRE (or any element using the CSS 
"white-space" property) if the Atom processor collapses whitespace?

<atom:content type="html"><![CDATA[
<p>Hello World! in C#:</p>
<pre>
class Main {
     static public void main() {
         System.Console.WriteLine("Hello World!");
     }
}
</pre>
]]></atom:content>

-- 
Thomas Broyer

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 18 Apr 2005 20:13:14 +0200

Thomas Broyer wrote:
> (or any element using the CSS "white-space" property)

That is purely for presentation. You should not use it if you need 
whitespace to be preserverd for semantics. (In such cases xml:space 
would probably be more appropriate...)

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

---

From: Graham <[email-masked]>
Date: Mon, 18 Apr 2005 19:19:33 +0100

> http://www.w3.org/TR/2004/REC-xml-20040204/#sec-white-space

It may be described there, but it doesn't do anything unless the 
vocabulary on top of HTML says it does.

> How are you supposed to write an HTML PRE (or any element using the 
> CSS "white-space" property) if the Atom processor collapses 
> whitespace?

The atom spec only references whitespace-collapsing in regards to 
type="text". It doesn't affect HTML.

Graham Parks

---

From: Tim Bray <[email-masked]>
Date: Mon, 18 Apr 2005 12:09:52 -0700

> "white-space collapsing":

Yes, I think this would be helpful.  It's obvious to hacks like us that 
line breaks are white-space, but possibly not to everyone.

> aren't normal for text/plain, which is the obvious analogy.

OK by me. -Tim

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 18 Apr 2005 21:28:58 +0200

> would probably be more appropriate...)

Right, but xml:space is applied to the XHTML "pre" element only when
using a DTD (if not explicitly "instanciated" on the element, which is
most likely not the case!).

<atom:content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<p>Hello World! in C#:</p>
<pre>
class Main {
     static public void main() {
         System.Console.WriteLine("Hello World!");
     }
}
</pre>
</div>
</atom:content>

Atom doesn't say how whitespace should be handled inside HTML or XHTML
content (text constructs or atom:content), nor inside extension elements.

> vocabulary on top of HTML says it does.

It *does* something: it can force the application to preserve whitespace.

The XML vocabulary defines where it applies, and XHTML applies it on 
several elements, including "pre".

> type="text". It doesn't affect HTML.

But, as said above, it doesn't define the behavior for type="html" and 
type="xhtml", which means the Atom processor might collapse whitespace 
anywhere (including XHTML "pre" element and escaped-HTML content).

My feeling is that whitespace should be preserved (not collapsed) in 
content that will probably be passed to a secondary processor, that is 
XHTML and HTML, and other inline content in atom:content.
As all whitespace characters are passed from the XML processor to the 
Atom processor, at least the spec should inform implementors that 
whitespace SHOULD (at least, maybe MUST) be preserved (as it may be 
significant) if the content is not processed by the Atom processor (e.g. 
"direct output" inside an (X)HTML document in the case of a Web-based 
aggregator, or given as input to a third-party application/library).

Moreover, xml:space should be allowed on text constructs and 
atom:content (at least when type="text") with a default value (default 
to xml:space="default" for type="text") to allow content like:
...
<atom:title type="text">RELAX NG book at O'Reilly</atom:title>
<atom:summary type="text">
...
RELAX NG covers the following topics in depth:
  - Introduction to RELAX NG
  - Building RELAX NG schemas using XML syntax
  - Building RELAX NG schemas using compact syntax, an alternative 
non-XML syntax
...
</atom:summary>

As extension elements are processed by the Atom processor and all 
whitespace is passed from the XML processor to the Atom processor, 
there's no need to define anything in the spec: Atom processors are 
responsible for handling extensions, thus whitespace 
collapsing/preserving of extension elements' content.

-- 
Thomas Broyer

---

From: Norman Walsh <[email-masked]>
Date: Mon, 18 Apr 2005 15:46:07 -0400

/ Graham <[email-masked]> was heard to say:
| I'd also like to remove the word "normal" from there, since these
| aren't normal for text/plain, which is the obvious analogy.

Do I get what I expect if I specify the content with the MIME type
"text/plain"? That is, a monospaced font with line breaks and other
whitespace preserved?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

---

From: fantasai <[email-masked]>
Date: Mon, 18 Apr 2005 20:08:24 -0400

> would probably be more appropriate...)

Even if you use xml:space to make the parser preserve white space,
unless the computed value of CSS 'white-space' is 'pre', a CSS
renderer must collapse the white space.

xml:space controls whether the parser collapses white space or
not. CSS 'white-space' controls whether the white space passed
from the parser to the renderer is collapsed or not. If the
parser collapses whitespace, CSS will never see it.

~fantasai

---

From: Tim Bray <[email-masked]>
Date: Mon, 18 Apr 2005 19:41:12 -0700

On Apr 18, 2005, at 5:08 PM, fantasai wrote:

> not.

False.  Parsers are not under any obligation to respect xml:space, 
unless they are governed by some other specification that says they 
are. -Tim

> If the

True. -Tim

---

From: Eric Scheid <[email-masked]>
Date: Tue, 19 Apr 2005 12:51:04 +1000

> unless they are governed by some other specification that says they

some other specification = Atom Pub spec?

e.

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 19 Apr 2005 07:31:16 +0300

> unless they are governed by some other specification that says they 

How can a spec other than the XML spec govern what XML processors do? 
Or is xml:space supposed to be handled somewhere between the XML 
processor and the app?

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

---

From: Tim Bray <[email-masked]>
Date: Mon, 18 Apr 2005 22:18:34 -0700

> Or is xml:space supposed to be handled somewhere between the XML 

An Atom processor, for example, is larger than the XML processor, which 
is a glorified input buffer and is anyhow forbidden from removing white 
space in element content.  xml:space is a value which may be used 
upstream in an XML transmission chain to express an intent about 
white-space handling to those further downstream in the chain.

It wouldn't break any rules for Atom to impose requirements on 
Atom-processing software as regards the handling of xml:space.  
However, I don't think we should.  The semantics are clear: someone 
upstream thinks this white-space is specific.  Whoever reads the Atom 
feed is at liberty to respect or to ignore xml:space.   Whatever we 
say, full-text indexers, for example, are guaranteed to ignore it.  I 
don't see where we can add any value.  -Tim