Subject: Re: text-only in atom:title?

From: "Bill Kearney" <[email-masked]>
Date: Tue, 31 Aug 2004 21:03:01 -0400

> Then you're not talking about entities, but real markup. If real markup
> should be allowed, I would like to restrict it to inline elements, but I
> think that path is such a slippery slope that I'm not very eager to run
> down it.

I agree, I can recall posing questions about markup during the early stages
of RSS.  There being no profile or subset of HTML, combined with silly
arguments about encoding and well-formedness lead to no real decision being
made.

It's perhaps much less of an issue.  Out of over 150k feeds there are a
total of TWENTY-SEVEN that attempt to use an encoded &gt; entity in their
channel title element.  Of these only ONE is using it as markup.  The rest
being simple (and proper) encoding of the > character.

Delving in further, in a recent polling of over 1,071,004 individual items
there were a total of only 484 that attempted to use an encoded &gt; as an
item title.  It appears less than a dozen are attempting to use markup.

Thus it's hard to present much of a case for markup based on existing usage
as the numbers just don't support it.

Bear in mind that I'm not opposed to how the client/server aspect of atom
would handle markup.  I'm opposed to entertaining use of it in a feed
context.  There's just not much good reason for grafting that sort of crap
(and the costs and risks it brings) into the descriptive title of a channel
or item.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Tue, 31 Aug 2004 11:53:29 -0400

> IMHO, the best that can be done is to (1) attempt to require content
> producers to explicitly declare whether or not markup is present, (2)
> inform producers that markup will be routinely stripped.

I'd support the default being text/plain and spec documentation clearly
indicating a strong preference for using such.  Indicating also that
including data outside the bounds of it's type (html in text/plain) is
invalid.

-Bill Kearney

---

From: Sam Ruby <[email-masked]>
Date: Wed, 01 Sep 2004 20:47:23 -0400

> including data outside the bounds of it's type (html in text/plain) is

Can you give an example of data that is "outside the bounds" for text/plain?

- Sam Ruby

---

From: Phil Ringnalda <[email-masked]>
Date: Thu, 2 Sep 2004 12:24:17 -0700

> as the numbers just don't support it.

One of the reasons Atom exists is because it wasn't possible to safely
use a &lt; in an item title, because of the completely unpredictable
results. I'm surprised that there were even that many people
attempting it, given how familiar we've become with the pain. Even Tim
probably wouldn't try his </TAG> title again.

Just because we aren't doing it in RSS doesn't mean we don't want to do it.

Phil Ringnalda

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 02 Sep 2004 21:34:20 +0200

> One of the reasons Atom exists is because it wasn't possible to
> safely use a &lt; in an item title, because of the completely
> unpredictable results. I'm surprised that there were even that many
> people attempting it, given how familiar we've become with the pain.
> Even Tim probably wouldn't try his </TAG> title again.
> 

Exactly. -1 to the text-only in atom:title proposal.

My titles did you use markup in the past, but since various weblog
systems had trouble with it I stopped using those and switched to
text-only. However, when I finally get a weblogging tool that does what
I want I want to be able to use things like the ABBR, CODE and more
elements in the title of my weblog entry.

The raison given that it is currently not used a lot doesn't make sense
at all. If we are just polishing RSS please say so and I will abandon
the Atom project and find out how RSS 1.0 works.

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

---

From: Dare Obasanjo <[email-masked]>
Date: Thu, 2 Sep 2004 12:50:02 -0700 (PDT)

> Just because we aren't doing it in RSS doesn't mean

No matter which way this discussion ends up going, Tim
will be able to have titles such as "</TAG>" since the
mechanism for determining the content type of a title
will be well defined. 

=====
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!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 2 Sep 2004 13:47:04 -0700

Here's what I have gleaned from the thread about the uses of 
atom:title that require more than plain text.

- Entities such as &gt;

- Proper bidirectional text markup (Arabic and Hebrew)

- Simple HTML/XHTML visual markup such as italics for book titles

- Multimedia and active content that probably almost no one wants in titles

Let me know if I missed some.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Tim Bray <[email-masked]>
Date: Thu, 02 Sep 2004 14:19:54 -0700

> atom:title that require more than plain text.

<MarkupPedantry>&gt; isn't more than plain text.  If you want the 
characters "<" or "&" in your title (which is reasonable, it's a 
perfectly OK character, e.g. "A & P Profits Down"), and you're in XMl, 
you have to encode them as &lt; and &amp; respectively.  You don't have 
to encode '>' as &gt;  except in very special circumstances which 
however could conceivably occur in a title, but anyhow the results 
would still just be '>'.  </MarkupPedant>

The rest, however, do seem to be the use-cases we've seen. -Tim

---

From: Phil Ringnalda <[email-masked]>
Date: Thu, 2 Sep 2004 14:25:48 -0700

> atom:title that require more than plain text.
<snip/>
> - Simple HTML/XHTML visual markup such as italics for book titles
<snip/> 
> Let me know if I missed some.

Don't forget proper, semantic markup which maintains the meaning of
the title, like abbr/acronym, code, or q. There's a big difference
between "I hate UPS" and "I hate <acronym title="Underwear Pucker
Syndrome">UPS</acronym>".

Phil Ringnalda

---

From: Sam Ruby <[email-masked]>
Date: Thu, 02 Sep 2004 17:55:32 -0400

Tim Bray wrote:
> however could conceivably occur in a title, but anyhow the results would 
> still just be '>'.  </MarkupPedant>

It might be pedantically correct, but based on my experience with users, 
it is not completely obvious.  Even experts get caught on "<'s Pointy 
End" on occasion.

Even if a careful reading of the relevant specifications would lead one 
to the correct answer, IMHO, in cases like these an informative example 
or two goes a long way.  Examples like "Ben &amp; Jerry&apos;s" or 
"AT&amp;T".  And if we do allow even a limited amount of markup, we 
should provide examples of how these interact.

> The rest, however, do seem to be the use-cases we've seen. -Tim

There were a number of other use cases mentioned: Ruby annotation, 
super/sub scripts, math formulas, etc.

The nice thing about (X)HTML is that even in the face of arbitrary 
markup there is a clean and simple way to fall back to plain text.  This 
is important: even if a given tool has a UI widget to handle HTML, some 
tools will chose to present titles in selection lists and containers - 
widgets that are only equipped to handle plain text.

- Sam Ruby

---

From: Martin Duerst <[email-masked]>
Date: Fri, 03 Sep 2004 10:34:13 +0900

At 17:55 04/09/02 -0400, Sam Ruby wrote:

>>>Here's what I have gleaned from the thread about the uses of atom:title 
>>>that require more than plain text.
>>>
>>>- Entities such as &gt;
>>to encode '>' as &gt;  except in very special circumstances which however 
>>could conceivably occur in a title, but anyhow the results would still 
>>just be '>'.  </MarkupPedant>
>
>it is not completely obvious.  Even experts get caught on "<'s Pointy End" 
>on occasion.
>
>Even if a careful reading of the relevant specifications would lead one to 
>the correct answer, IMHO, in cases like these an informative example or 
>two goes a long way.  Examples like "Ben &amp; Jerry&apos;s" or 
>"AT&amp;T".  And if we do allow even a limited amount of markup, we should 
>provide examples of how these interact.

Yes. The important point is to not list it under markup, but to have
a separate section at the end saying something like:
For completeness: Not markup, needed to represent plain text

>The nice thing about (X)HTML is that even in the face of arbitrary markup 
>there is a clean and simple way to fall back to plain text.  This is 
>important: even if a given tool has a UI widget to handle HTML, some tools 
>will chose to present titles in selection lists and containers - widgets 
>that are only equipped to handle plain text.

Very good point. Even in case we would specify exactly which elements
are allowed (which I agree we shouldn't), we should not specify how
these things have to be presented.

Regards,   Martin.

---

From: Martin Duerst <[email-masked]>
Date: Fri, 03 Sep 2004 10:37:40 +0900

>that require more than plain text.

Move to the end in a separate section.

>Let me know if I missed some.

- Ruby (already mentioned by Sam :-).

- Use of images to deal with extremely rare and not yet encoded characters,
   specific character variants that Unicode doesn't distinguish, and logos
   of all kinds.
   (mentioned to some extent by Norm)

- Semantic markup, including language markup (for text-to-speech)
   (mentioned to some extent by Phil)

Many of these uses are rare, but it's not clear to me whether
they are rare because there is not much need, or whether they
are rare because there is not enough support.

Regards,   Martin.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 2 Sep 2004 18:41:08 -0700

At 2:19 PM -0700 9/2/04, Tim Bray wrote:
>perfectly OK character, e.g. "A & P Profits Down"), and you're in 
>XMl, you have to encode them as &lt; and &amp; respectively.  You 
>don't have to encode '>' as &gt;  except in very special 
>circumstances which however could conceivably occur in a title, but 
>anyhow the results would still just be '>'.  </MarkupPedant>

A simple sign-reversal error. :-)

>Syndrome">UPS</acronym>".

Thanks.

>super/sub scripts, math formulas, etc.

Thanks.

That brings the list to:

- Entities such as &lt; and &amp;

- Positional formatting of text in the title, such as super/subscript 
and math formulae

- Semantic markup which wraps parts of the title while retaining the 
meaning of the title

Let me know if I missed some more.

--Paul Hoffman, Director

---

From: "Bill Kearney" <[email-masked]>
Date: Thu, 2 Sep 2004 21:39:15 -0400

> My titles did you use markup in the past,

Care to offer examples of how this would be useful/needed in the context of
a feed's titles?

> but since various weblog

I'm all for the ability to indicate the type and use any number of
constructs within the content of an entry.  I'm against using anything other
than "plain text" inside the title element as it would be consumed from a
feed.

> at all.

Ok, let's present reasons.  I'm against them in the context of a feed-like
instance.  If we wanted to use <title alt="plain text"
type="mime/type">whatvergodforsakengibberishyoulike</title> that might be a
reasonable compromise I could support.

> If we are just polishing RSS please say so and I will abandon

So what then, take your ball and go home?

-Bill Kearney

---

From: Walter Underwood <[email-masked]>
Date: Thu, 02 Sep 2004 20:20:53 -0700

> - Proper bidirectional text markup (Arabic and Hebrew)

Nope. Bidi can be done in text/plain, using Unicode controls.
In XHTML, the Unicode controls are deprecated in favor of bidi
controls expressed in markup.

Bidi is not a reason to allow markup.

> - Positional formatting of text in the title, such as super/subscript

The most common cases are already available in Unicode. Math formualae
are not a real use case. Math greek, yes, but not a forumula which
requires vertical formatting.

> Let me know if I missed some more.

<blink>. Gotta have blinking titles.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Sam Ruby <[email-masked]>
Date: Fri, 03 Sep 2004 07:05:31 -0400

> Bidi is not a reason to allow markup.

True statements, but let's explore how this is done.

First with HTML markup:

   English <span dir="rtl">Hebrew</span> English

Now in utf-8 (where bracketed data is hex bytes):

   English [E280AE]Hebrew[E280AD] English

Such an approach is not possible in iso-8859-1, but can be accomplished 
with entities:

   English &#x202E;Hebrew&#x202D; English

This is not an area of my expertise, but the reason I'm pointing this 
out is to highlight the human factors aspects of this.  Not all software 
has adequate support for RTL languages like Hebrew.  Many simply present 
a form with a text entry area for title.

For these reasons, it is often recommended that the markup is prefered 
in editing contexts.  It seems that many people prefer markup over 
entering invisible marker characters.

My reason for bringing this up: I can understand a position where no 
markup is permitted, and in the context of such a position, I would 
agree that "Bidi is not a reason to allow markup".  However, I would 
argue that if markup is allowed for other reasons, then the markup which 
indicates right to left should be included in the set of allowed constructs.

- Sam Ruby

---

From: Ian Davis <[email-masked]>
Date: Fri, 03 Sep 2004 14:47:48 +0100

From a pragmatic point of view, any markup in atom:title ought to be 
directly embeddable in an html:p or html:div since the most common usage 
will be to create an XHTML page and display to end user.

If not, there needs to be guidelines about how client apps can include 
snippets of arbitrary markup in valid XHTML.

Ian

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 3 Sep 2004 08:10:56 -0700

>controls expressed in markup.

I said *proper* bidirectional text markup. The folks in the Unicode 
Consortium generally agree that it is better to use XHTML controls 
instead of Unicode controls where possible; it's not just a W3C thing.

--Paul Hoffman, Director

---

From: Walter Underwood <[email-masked]>
Date: Fri, 03 Sep 2004 09:02:07 -0700

> entering invisible marker characters.

That is a data entry issue, not a feed format issue. It isn't much
different from generating &amp; for &. Tools can accept the bidi
markup and traslate it to Unicode controls.

> indicates right to left should be included in the set of allowed

+1, except that in markup the bidi markup is preferred, not just allowed.

wunder
--
Walter Underwood
Principal Architect
Verity Ultraseek

---

From: Martin Duerst <[email-masked]>
Date: Sat, 04 Sep 2004 10:17:14 +0900

Hello Sam, others,

I fully agree with your statement at the end. Also, the point
is well made that it is often preferable to use bidi in markup
(rather than Unicode codes) for source editing (in particular
because the markup in the source makes some cases behave quite
differently when you look at the source from when you look at
the final result.

However, the example you choose,
     English <span dir="rtl">Hebrew</span> English
is too simple. There is no need for markup or format control
characters in this case, this is handled by what's called the
'implicit' part of the Unicode bidirectional algorithm.

Regards,    Martin.

At 07:05 04/09/03 -0400, Sam Ruby wrote:

>This is not an area of my expertise, but the reason I'm pointing this out 
>is to highlight the human factors aspects of this.  Not all software has 
>adequate support for RTL languages like Hebrew.  Many simply present a 
>form with a text entry area for title.
>
>For these reasons, it is often recommended that the markup is prefered in 
>editing contexts.  It seems that many people prefer markup over entering 
>invisible marker characters.
>
>markup is permitted, and in the context of such a position, I would agree 
>that "Bidi is not a reason to allow markup".  However, I would argue that 
>if markup is allowed for other reasons, then the markup which indicates 
>right to left should be included in the set of allowed constructs.
>
>- Sam Ruby

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 3 Sep 2004 12:02:57 -0400

> Syndrome">UPS</acronym>".

And does this belong in a title element of a feed?  Why is this not more
appropriately placed in the content itself?  I'm all for the content capable
of being as robust as every uselessly precise nitpicking wonk wants it to be
(to which I can confess to being from time to time).  I see, however, little
merit to jamming it into title elements and burdening whatever tools process
them with ripping it all out so a title can be shown.

I suspect a search of such markup would find next to no use of it at the
present.  While I'm all for the ability to use robust markup in content I
continue to see little or no value in jamming it into titles.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Mon, 6 Sep 2004 16:22:07 -0400

>    specific character variants that Unicode doesn't distinguish, and logos

Glyphs for language is one thing, logos are another thing entirely.

> are rare because there is not enough support.

Well, it's always tough to strike the right balance.  If there's a
significant body of material and/or sources that are interested in having
these features then that has to be balanced against the hassles imposed on
consuming programs in processing them.  Just because something might
theoretically 'need it' doesn't mean its costs should be forced onto the
consuming audience.

As an aside, if a language is spec'd for a feed then is that also the place
for statements regarding directionality of the text (rtl vs ltr)?

-Bill Kearney

---

From: "Jon Meyer" <[email-masked]>
Date: Mon, 6 Sep 2004 19:02:31 -0400

The discussion about atom:title appears to revolve around what role it
occupies:

a) Is atom:title the *name* of the entry. Is it equivalent to a filesystem
filename, HTML <title>, Email Subject etc? In which case it *should* be a
Unicode string, and the standard should state that the title is *not* to
rendered by user agents as part of the flow of the document, but instead as
a window header or in a title-bar area (leave it to the <content> section to
specify the heading). HTML sets a good precedent here.

Or 

b) Is atom:title the *heading* for an entry, i.e. part of the flow of the
document containing the heading? If it is part of the document flow, it
certainly requires font, color, style, etc. so that it integrates with the
rest of the document flow. (e.g. consider a document with a black
background). And then doesn't Atom require some alternate mechanism to
address the *name* role?

The current draft is ambiguous about which of these roles atom:title
occupies. Atom:title is defined as a content element, suggesting (b). But
most of the use-cases I've seen imply (a).

Perhaps Atom is aiming to conflate these two roles? I don't know of any
document system that has done this successfully. If atom:title is
plain-text, shouldn't the standard specify how feed producers can control
its appearance to make it consistent with the document flow? Do feed
producers add an extra copy of the document title at the start of the
<content>? If it contains markup, how do you extract a canonical plain-text
name?

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 6 Sep 2004 17:09:32 -0700

>background). And then doesn't Atom require some alternate mechanism to

*Excellent* summary of the base question. Thanks!

>most of the use-cases I've seen imply (a).

Most of the use-cases are based on the syntax given so far. If the 
syntax allow (b), creative people would certainly start using it that 
way.

>Perhaps Atom is aiming to conflate these two roles?

Probably.

>  I don't know of any
>its appearance to make it consistent with the document flow?

No, but an implementer's guide should discuss the issue.

>  Do feed
><content>?

Why would they do that if it was the *name* of the entity?

>  If it contains markup, how do you extract a canonical plain-text
>name?

And why would they need to do that if it isn't really a name?

This WG really should pick one of the two directions and let the 
syntax follow from the decision.

--Paul Hoffman, Director

---

From: "Jon Meyer" <[email-masked]>
Date: Mon, 6 Sep 2004 20:36:17 -0400

> syntax follow from the decision.

To clarify my position, I believe Atom needs both, not one or other. 

Rewriting my last para: If atom:title is a *name*, feed producers will want
a way to create a *heading* that appears consistent with the document flow
(e.g. matching document fonts and colors). 

If atom:title is a *heading*, Atom users will want a standard canonical way
to extract a plain-text *name* for an entry, e.g. for displaying in a
ListBox showing all the entries in a feed, or in a Bookmarks list, etc.

Cheers

Jon

---

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

> ListBox showing all the entries in a feed, or in a Bookmarks list, etc.

Fairly good results can be found by following the HTML spec[1]

     If a user agent encounters an element it does not recognize, it
     should try to render the element's content.

There are a few areas where this is problematic[2]

     The "ignore unrecognized markup" convention is unacceptably
     unreliable in cases such as forms and tables.

However, these elements are unlikely to appear in titles.

- Sam Ruby

[1] http://www.w3.org/TR/REC-html40/appendix/notes.html#h-B.1
[2] http://www.w3.org/MarkUp/WD-doctypes

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Mon, 6 Sep 2004 19:17:57 -0700

>However, these elements are unlikely to appear in titles.

A different view is that titles that include markup MUST have an alt attribute.

--Paul Hoffman, Director

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 6 Sep 2004 22:27:26 -0400

Jon Meyer wrote:
> a) Is atom:title the *name* of the entry. Is it equivalent to
> a filesystem filename
	I think the unique name for an entry is the atom:id. All else is
content.

		bob wyman

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Sep 2004 23:08:12 +0200

* Norman Walsh wrote:
>That might work fine for Atom, I won't argue against it, though it will
>become FAQ why you can't put super/subscripts in them. Or images. Or MathML.
>Or any of a host o fother things that require markup.

You mean like all the people asking how to embed MathML in the Subject:
header in Emails or Usenet articles? And you can put sub- and super-
scripts there, ² for example works just fine.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 09 Sep 2004 23:05:58 +0200

>will be to create an XHTML page and display to end user.

Anything is directly embeddable in html:div.

>snippets of arbitrary markup in valid XHTML.

Who cares about valid XHTML? What would such an application do if that
inclusion would not be valid, e.g. if there is a nobr element? Would
such applications attempt to check for conformance at all?

---

From: Ian Davis <[email-masked]>
Date: Thu, 09 Sep 2004 23:19:12 +0100

> Anything is directly embeddable in html:div.
Not strictly true. legend isn't.

> such applications attempt to check for conformance at all?

Exactly my point, which is why I suggested that a pragmatic view is that 
markup in atom:title ought to follow the xhtml div or p content model.

Ian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 10 Sep 2004 00:34:34 +0200

>Not strictly true. legend isn't.

Well, it might not be allowed in some

>markup in atom:title ought to follow the xhtml div or p content model.

revision of the specification. Which do you mean here, exactly? XHTML
Mobile 1.0? XHTML 1.0 Transitional? XHTML 1.1? Some home-grown XHTML
dialect? XHTML 1.1 + SVG 1.1 + MathML 2.0 + SMIL 2.0 + XBL 2.0 + XUL?

---

From: Ian Davis <[email-masked]>
Date: Fri, 10 Sep 2004 00:04:08 +0100

> dialect? XHTML 1.1 + SVG 1.1 + MathML 2.0 + SMIL 2.0 + XBL 2.0 + XUL?
What's your suggestion for a solution? Faced with an atom:title 
containing arbitrary markup how should a newsreader display this?

Ian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 10 Sep 2004 01:35:00 +0200

>containing arbitrary markup how should a newsreader display this?

Writing some constraint into the specification does not remove this
problem for implementations, and I would thus suggest they treat it
as they would treat any other unexpected markup, a blink element for
example. There are some options here,

  * reject the entry or document 
  * assume something about the content and attempt to process the markup
  * replace the title with something like "invalid title"
  * process only the parts of the title they can understand like
    any text preceding the first start tag
  * concatenate all #PCDATA and take that as the title

each of which breaks under certain circumstances or provides poor user
experience. Poor user experience is also what you might get if expected
markup is allowed, for example if the content is rendered much too small
than what would be appropriate if there is insufficient space in the
title display widget.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 10 Sep 2004 02:31:39 +0200

* Sam Ruby wrote:
>markup there is a clean and simple way to fall back to plain text.

It would be nice if it were clean but it is not. Script content and
style sheets for example should not be rendered to users, in HTML
this has led to

  <script ...><!--
    ...
  //--></script>

in order to hide the content from old user agents that did not support
the script and style elements. You find similar examples when people
attempt to embed RDF fragments in HTML documents for which they again
need to use comments to hide the content. Rendering anything unknown is
clearly a non-starter if you wish to be compatible to downlevel-clients.

---

From: Phil Ringnalda <[email-masked]>
Date: Thu, 9 Sep 2004 17:52:17 -0700

On Fri, 10 Sep 2004 02:31:39 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
> 
> You find similar examples when people

Actually, no. That's generally done to hide the invalid-in-XHTML RDF
from the validator, not to hide it from UAs, from whom it's already
hidden by the minimized form: neither Creative Commons nor Trackback
(the two primary embedders of RDF) *have* any content, intentionally.
<style> in the <body> isn't unknown, it's invalidly out of place, and
<script> is the exception everyone writing a UA knows about. Other
than that, if you don't know, you show, a thing that extension
designers really ought to keep in mind ("What would this look like if
something displayed it as 'element-name: content'?  Crap? I better use
an attribute instead.")

Phil Ringnalda

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 10 Sep 2004 00:55:39 -0400

On Fri, 10 Sep 2004 02:31:39 +0200, Bjoern Hoehrmann <[email-masked]> wrote:
> the script and style elements.

That would be Netscape 3.  You can stop doing that now.

-- 
Cheers,
-Mark

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Fri, 10 Sep 2004 08:10:15 +0200

> That would be Netscape 3.  You can stop doing that now.

[Semi-OT]
The first Netscape version with scripting support was 2.0. Virtually every  
browser released since that have not needed any sort of comments in HTML  
script blocks.

Pop quiz: Why did I write "any sort of comments", and why did I  
specifically not write "XHTML"?

[/Semi-OT]

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 10 Sep 2004 09:06:38 -0400

> than what would be appropriate if there is insufficient space in the

I agree.  I'm also looking at this from an evolutionary perspective.  Right
now we're talking about moving content of the items themselves up and out of
the morass of encoded HTML.  Given how poorly many a developer grasped that
basic a concept is it perhaps reasonable to take things in incremental
steps?  Instead of pushing whole-hog for everything everywhere (often soley
for 'the sake of doing it') how about recognizing the difficulties just
having this in item entries will present?

Or look at it this way, what's going to increase adoption of it?  Will
having a spec capable of mashing everyhing and the kitchen sink into a title
element help or hinder adoption?  Let's not repeat the mistakes of other
formats (who probabl should remain nameless) of making specs that nothing
could implement, let alone properly.

-Bill Kearney
Syndic8.com

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 10 Sep 2004 10:25:32 -0400

Bill Kearney wrote:
> Will having a spec capable of mashing everyhing and the kitchen sink
into
> a title element help or hinder adoption?
	Personally, I think that markup in the titles is going to cause
more problems then it is worth. It also muddies the architecture of the
system.
	The whole point of these "syndication" formats (RSS, CDF, Atom,
etc.) was to provide machine readable "summaries" or proxies for sites
and parts of sites. As I understand it, the idea was to break away from
a pure "presentation" format and move instead to something which could
carry semantic content... If you're preparing an entry, your focus
should be on transmitting *information* not presentation. Rendering is
up to the program that receives your entry or, if you want to do it,
then that is what the "alternate" link is for.
	I strongly feel that presentation oriented markup should be
prohibited from any element other than content. (If you need javascript,
Active/X controls, H1 elements or CSS in order to markup your "title"
the way you want it, then you probably have the "title" element confused
with some other element... E.g. "content") I would go further to say
that it should be considered a "good practice" to minimize the use of
presentation markup in the content element. 

		bob wyman

---

From: "jt" <[email-masked]>
Date: Fri, 10 Sep 2004 11:24:31 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bob Wyman
| Sent: Friday, September 10, 2004 10:26 AM
| To: 'Bill Kearney'
| Cc: 'Atom WG'
| Subject: RE: Summary of non-text-only uses of atom:title
|
|
|
| Bill Kearney wrote:
| > Will having a spec capable of mashing everyhing and the kitchen sink
| into
| > a title element help or hinder adoption?
| 	Personally, I think that markup in the titles is going to cause
| more problems then it is worth. It also muddies the architecture of the
| system.
| 	The whole point of these "syndication" formats (RSS, CDF, Atom,
| etc.) was to provide machine readable "summaries" or proxies for sites
| and parts of sites.

I think the original question was self-answering, personally.

The facts of the matter are this:  People aren't going to bow down to your
spec, if it doesn't accomplish even the simplest things that people want to
do with syndication.  Italics in a title a problem, then your spec has a
serious problem as does the 'thinking' that's gone into it.

http://akma.disseminary.org/archives/001542.html

And did anybody ask Joi Ito's opinion on this subject, because (in spite of
the 'cowboy approach' I've previously admired) he's indicated (about a year
ago) these kinds of bogus restrictions are going to be thrown aside no
matter what you all choose to dictate.  Although he backed off from breaking
aggregators for a time, that indicates he and/or others will have a need in
the future, unless you successfully squash it somehow.

And whether the format is machine readable, it will in some form or another
(raw or re-formatted doesn't matter) eventually be displayed to a person.

That muddies things up for those who think, falsely, that programs will
communicate with programs and the 'ugly' human element doesn't really NEED
to EVEN come into play.  Lez optimize for that GREAT POTENTIAL, the lamer's
say.. and better yet figure that's the ONLY useful content to be syndicated.
Like I said, I haven't followed close enuf, but if the resulting spec
reflects the view that humans are a problem, I can assure you there will be
only-some adoption, and that will be 5 or 10 years down the road, at best,
instead of 1 or 2 years down the road.

Take yer pick.  Going by your ostensible goals, I'd think you would want to
allow markup in titles.

---

From: Brett Lindsley <[email-masked]>
Date: Fri, 10 Sep 2004 11:06:12 -0500

How about machine readable titles with an (optional) alternate link to a
marked-up version for the humans? Brett.

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 10 Sep 2004 09:45:12 -0700 (PDT)

> http://akma.disseminary.org/archives/001542.html

If content producers think they have absolute control
over how their content is rendered on the client then
there is a 'serious problem in the thinking' they've
used to approach the issue. 

RSS Bandit strips markup from titles in RSS and if
Atom allows markup in titles it will strip that as
well. 

I also strip a bunch of CSS related markup since they
usually interfere with the XSLT based skins a user has
chosen to apply for viewing items in the reading pane.

If Atom allows markup in titles, I'll be fine with it
since I always plan to strip it anyway. However
content producers shouldn't think that since they can
place presentation markup in feeds that it actually
will end up being viewed by the end user. 

=====

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

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 10 Sep 2004 13:56:50 -0400

> will end up being viewed by the end user.

+1.  My Universal Feed Parser applies a whitelist [1] of HTML elements
and attributes before the calling application even gets any data back.
 The default whitelist is brutal: script, applet, embed, object, meta,
link, the style element and attribute, and all on* attributes are all
stripped (i.e. not included in the whitelist).  People usually
complain initially, until they see my unit tests. [2]  (This is my
favorite: [3])

Never trust your upstream platypus. [4]

[1] http://feedparser.org/docs/html-sanitization.html
[2] http://feedparser.org/tests/wellformed/sanitize/
[3] http://feedparser.org/tests/wellformed/sanitize/entry_title_crazy.xml
[4] http://diveintomark.org/public/platypus.xml

-- 
Cheers,
-Mark

---

From: Phil Ringnalda <[email-masked]>
Date: Fri, 10 Sep 2004 12:22:40 -0700

On Fri, 10 Sep 2004 09:45:12 -0700 (PDT), Dare Obasanjo <[email-masked]> wrote:
> since I always plan to strip it anyway.

How about if it doesn't allow markup in titles? Are you going to
display literally:

Just finished <i>Moby Dick</i>
School is <b>fun!</b>
<acronym title="eXtensible Markup Language">XML</acronym> is tough!

in order to be able to display the one-in-a-million actual title
intending a plain text thing that looks like an HTML tag

Proper use of <h1>headers</h1>

or are you going to decide that all &lt;s in titles are markup leaking through?

Allow markup in titles, and everyone knows what to do. Don't allow it,
and you have the current situation, sometimes it's stripped, sometimes
it's escaped, sometimes it displays, only slightly improved by having
clear spec text to point at while saying "my aggregator may look like
crap with your title, but I'm right and you're wrong, nyah."

Phil Ringnalda

---

From: "jt" <[email-masked]>
Date: Fri, 10 Sep 2004 17:46:57 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Dare Obasanjo
| Sent: Friday, September 10, 2004 12:45 PM
| To: jt; [email-masked]; 'Bill Kearney'
| Cc: 'Atom WG'
| Subject: RE: Summary of non-text-only uses of atom:title

| If content producers think they have absolute control
| over how their content is rendered on the client then
| there is a 'serious problem in the thinking' they've
| used to approach the issue.

Do you not see?  This is why it's been a perma-thread for seemingly decades.
If you think 20-something coders have absolute control over the content they
are going to be SENT, and even more that they SHOULD, then you'd be working
for IBM or MicroSoft or Sun or Oracle or their ilk, most likely.

The usual suspects want ABSOLUTE control over things they canNOT POSSIBLY
HAVE absolute control over, jes fer the heckuvit, I s'pose.

Stuff like who's paying for the bandwidth, and what ARE the economics..
Well, these don't factor in as concerns to coders, nor "Open" Source,
good-for-nothing-and-pay-that-much users, either one.

| If Atom allows markup in titles, I'll be fine with it
| since I always plan to strip it anyway. However
| content producers shouldn't think that since they can
| place presentation markup in feeds that it actually
| will end up being viewed by the end user.

If Atom allows markup in titles, then YOUR non-paying end user's will not
see any benefit whatsoever, right?  Isn't that what you meant to say??
Meanwhile, you've probably killed any incentive for those who are CURRENTLY
USING RSS2 to adopt Atom, which may or may not be an unintended consequence.
But that won't bother you, because you lose no money by your decision,
right?

(That's the advantage of letting paying user's have MUCH more say in the
"Open" Standards process, and/or their representatives, btw...;-)

I think I've made too many points already, so backing away slowly...  But
I'll be looking for a (hopefully more reasonable than my) reply to Phil
Ringalda's recent post.

---

From: Dare Obasanjo <[email-masked]>
Date: Fri, 10 Sep 2004 14:57:54 -0700 (PDT)

> Proper use of <h1>headers</h1>

I strip anything that looks like HTML. This is what I
already do in RSS Bandit and after over 80,000
downloads this year I haven't seen one person complain
about it. 

> crap with your title, but I'm right and you're

I don't care if markup is allowed in titles or not. So
I'm going back to ignoring this thread. You guys can
decide what you want, regardless of what the decision
is RSS Bandit will strip stuff that looks like markup
from titless. 

=====

_______________________________
Do you Yahoo!?
Shop for Back-to-School deals on Yahoo! Shopping.
http://shopping.yahoo.com/backtoschool

---

From: "jt" <[email-masked]>
Date: Fri, 10 Sep 2004 18:07:44 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Dare Obasanjo
| Sent: Friday, September 10, 2004 5:58 PM
| To: Phil Ringnalda; [email-masked]
| Subject: Re: Summary of non-text-only uses of atom:title

| I strip anything that looks like HTML. This is what I
| already do in RSS Bandit and after over 80,000
| downloads this year I haven't seen one person complain
| about it.

I "lied".  Futures change.  I'm going to reply to Bill Kearney also, so sue
me.

I'm not gonna let some youngster claim that giving away 80,000 copies of
ANYTHING signifies.

Even if it is too subtle for some to notice that was your point, I feel
obligated to point that out, jes in case.

Do what you do, and the results will speak for themselves.

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 10 Sep 2004 18:17:01 -0400

> Do you not see?

Sure, and unfortunately it sounds like some geezer whining about "you kids
and your markup...."

> This is why it's been a perma-thread for seemingly decades.

Decades?  Surely you underestimate!  More like centuries. I'm sure someone
screamed about wasted materials when carving up marble for temples too.
Taking up too many sheep hides for those danged manuscripts, etc...

> see any benefit whatsoever, right?  Isn't that what you meant to say??

Strangely if found Dare's response was entirely reasonable.

He's erring on the side of caution.  That is, pull the content back to its
least common denominator for how his program can best display a "TITLE" for
an item from a feed.  Thus shaving off copious amounts of time that would be
wasted trying (coding and processing) to make sure the 3-panel view of this
aggregator had a chance of making the damn junk display AT ALL.

> USING RSS2 to adopt Atom,

What're you taking pages out of Winer's playbook now?  Yeesh.

> which may or may not be an unintended consequence.

Yeah, as if there was actual money involved in being able to publish
marked-up titles.

-Bill Kearney

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 10 Sep 2004 18:13:46 -0400

> <acronym title="eXtensible Markup Language">XML</acronym> is tough!

Just finished Moby Dick
School is fun!
XML is tough!

That's plain old text with markup stripped.

> and you have the current situation

Which I've shown is such an small amount of sitautions as to be
statistically irrelevant.

Let 'em have whatever the hell they want in a title but make them mark it up
appropriately.

Strongly encourage use of plain text in the spec.

Favor: <title>some plain ol&apos; text</title>
Over: <title alt="Markup Mania!"
type="text/html"><i>Markup</i><b>Mania!</b></title>

Then wait and see if any of these whining gits actually stand up and write
the gawd-awful code necessary to effectively wrangle all their beloved
markup into what the aggregator users actually WANT TO SEE on their screens?

-Bill Kearney

---

From: "jt" <[email-masked]>
Date: Fri, 10 Sep 2004 18:23:00 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bill Kearney
| Sent: Friday, September 10, 2004 6:14 PM
| To: [email-masked]
| Subject: Re: Summary of non-text-only uses of atom:title

| Which I've shown is such an small amount of sitautions as to be
| statistically irrelevant.

All polls are largely driven by the question(s) asked, and how they are
phrased.  The math adds up, but doesn't answer the question.

I forget who I saw already pointed out:  Given that markup is NOT generally
allowed, how many would you EXPECT to use it?  THEN divide.

ESTIMATE (and/or experiment and/or create an 'honest' survey) how many WOULD
use the feature if available, then MULTIPLY by new-adopters-over-the-years.
Statistics get in the way, is my main point, in this case.

---

From: "jt" <[email-masked]>
Date: Fri, 10 Sep 2004 18:34:22 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bill Kearney
| Sent: Friday, September 10, 2004 6:17 PM
| To: jt; Dare Obasanjo; [email-masked]
| Cc: 'Atom WG'
| Subject: Re: Summary of non-text-only uses of atom:title
|
|
|
| > Do you not see?
|
| Sure, and unfortunately it sounds like some geezer whining about "you kids
| and your markup...."
|
| > This is why it's been a perma-thread for seemingly decades.
|
| Decades?  Surely you underestimate!  More like centuries. I'm sure someone
| screamed about wasted materials when carving up marble for temples too.
| Taking up too many sheep hides for those danged manuscripts, etc...
|
| > If Atom allows markup in titles, then YOUR non-paying end
| user's will not
| > see any benefit whatsoever, right?  Isn't that what you meant to say??
|
| Strangely if found Dare's response was entirely reasonable.
|
| He's erring on the side of caution.  That is, pull the content back to its
| least common denominator for how his program can best display a
| "TITLE" for
| an item from a feed.  Thus shaving off copious amounts of time
| that would be
| wasted trying (coding and processing) to make sure the 3-panel
| view of this
| aggregator had a chance of making the damn junk display AT ALL.
|
| > Meanwhile, you've probably killed any incentive for those who are
| CURRENTLY
| > USING RSS2 to adopt Atom,
|
| What're you taking pages out of Winer's playbook now?  Yeesh.
|
| > which may or may not be an unintended consequence.
| > But that won't bother you, because you lose no money by your decision,
| > right?
|
| Yeah, as if there was actual money involved in being able to publish
| marked-up titles.
|
| -Bill Kearney

Nothing you do surprises me much, Bill, other than you appear to be very
successful.  Congrats, but your reply doesn't seem strange at all.

I never said being young made you wrong in each and every case, but if you
want to take my reply that way then that would be your loss.  Unfortunately
you have influence, so it's not ONLY your loss.

And I never WAS Winer's lap dog, contrary to your perception.  That pov was
a matter of convenience for many besides you and/or a lack of intellectual
rigor.  Winer and I are neither friends nor enemies (the latter is afaik,
mebbe we are enemies?).  I think we both made our points here, with your
lack of perception so fully exposed.

Doesn't mean you'll be wrong next time, necessarily.  Unless you're talking
about i5, which is the basis of your disgust with me, as you and I both
KNOW.. uhhh.. 'very' well.

Btw, I'm not a big fan of advertising.  But I wouldn't necessarily want to
lock ALL creative user's and uses out of the Atom spec, or you might (and I
say might, literally, dunno) find you face either a competitor in the spec
biz and/or non-adoption.  I'm not saying this in favor or against Atom, but
because I believe that is the case.  Assuming you want Atom to be adopted
the easiest, broadest, soonest as possible, I mean.

No time for an I-hate-you-and-the-i5-you-rode-in-on permathread, "Mr."
Kearney et al...  Alas, might be entertaining.

---

From: Phil Ringnalda <[email-masked]>
Date: Fri, 10 Sep 2004 16:29:34 -0700

> is RSS Bandit will strip stuff that looks like markup

Yep, which is exactly what I both feared and expected. If we allow
markup in title, and Tim rejoins the TAG after all this fun, and
correctly titles his post

<title type="text/html">&amp;lt;&lt;acronym title="Technical
Architecture Group">TAG&lt;/acronym>&gt;</title>

then RSS Bandit will display it as

<TAG>

and if we do not allow markup, and he correctly titles his post

<title>&lt;TAG></title>

then RSS Bandit will display it as an untitled post.

Phil Ringnalda

---

From: Ian Davis <[email-masked]>
Date: Sat, 11 Sep 2004 00:58:20 +0100

> Architecture Group">TAG&lt;/acronym>&gt;</title>
Can you explain this further. The characters the application will get 
after XML parsing are:

&lt;<acronym title="Technical Architecture Group">TAG</acronym>>

Ian

---

From: Phil Ringnalda <[email-masked]>
Date: Fri, 10 Sep 2004 17:22:06 -0700

> &lt;<acronym title="Technical Architecture Group">TAG</acronym>>

Whew. I got it right, then. Without a preview, I wasn't quite sure.
When Tim left the TAG, his post was titled "</TAG>". If he rejoins,
later, having gained even more readers who don't know him from W3C
things, he might want to explain to browsers of a list of titles-only
(say that by then Planet Sun can only afford to syndicate a title and
a link, nothing more) what he meant by "<TAG>", thus the acronym. If
it makes it more humanly-parseable, go ahead and encode the &gt; at
the tail end, though it isn't required. I drop that in an HTML
renderer, and I get <TAG> with a tooltip saying "Technical
Architecture Group", I run it through an HTML-stripper and de-encoder
and drop it in a text renderer and I get <TAG>.

Phil Ringnalda

---

From: Ian Davis <[email-masked]>
Date: Sat, 11 Sep 2004 01:43:44 +0100

> and drop it in a text renderer and I get <TAG>.

Thanks. I understand better now.

Can RSS Bandit can still strip tags safely by looking at the type 
attribute?

If there's no attribute or type="text/plain" then it can output 
verbatim, type="text/html" or type="application/xhtml+xml" it can strip 
and output result.

Ian

---

From: Phil Ringnalda <[email-masked]>
Date: Fri, 10 Sep 2004 18:39:31 -0700

> verbatim, type="text/html" or type="application/xhtml+xml" it can strip

As long as it uses a text renderer to display titles. If it's an HTML
renderer, and markup is just forbidden for display or validity
reasons, then & and < in text/plain get escaped, and (X)HTML just gets
a tagectomy

Phil Ringnalda.

---

From: Mark Pilgrim <[email-masked]>
Date: Fri, 10 Sep 2004 22:24:24 -0400

> reasons, then & and < in text/plain get escaped, and (X)HTML just gets

+1 for coining the term "tagectomy".

-- 
Cheers,
-Mark

---

From: Eric Scheid <[email-masked]>
Date: Sat, 11 Sep 2004 15:14:13 +1000

> is RSS Bandit will strip stuff that looks like markup

even with this:

    <title type="text/plain">&lt;blink&gt; is evil</title>

e.

---

From: Eric Scheid <[email-masked]>
Date: Sat, 11 Sep 2004 15:18:27 +1000

>> <acronym title="eXtensible Markup Language">XML</acronym> is tough!

<strikethru> is often used in titles for more than presentation effect...

    Bill Kearny is <strikethru>not</strikethru> smart!

e.

---

From: Danny Ayers <[email-masked]>
Date: Sat, 11 Sep 2004 12:22:54 +0200

I have no objection to either mandating (XML-compatible) plain text in
the title or allowing markup. My aggregator strips markup from titles,
content, passing pedestrians and low-flying aircraft, I don't care.
But that's irrelevant, supporting markup in titles shouldn't be
difficult in itself, reusing the <content> syntax.

All the arguments about malicious markup can be applied equally well
to <content>, so if the problem is dealt with there it can be dealt
with in titles too. If supporting this is deemed an unnecessarily
burden on consumer developers, fair enough. I really don't mind either
way, I just find it confusing when current user practice in RSS is
used to justify some parts of the spec, and then ignored in others. At
present people can and do dump markup in titles, irrespective of how
different aggregators handle it.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Bill Kearney" <[email-masked]>
Date: Sat, 11 Sep 2004 08:51:31 -0400

That's kearney with an e please.  But I'm sure you get i before e
mispellings too.

The only problem with arguments about markup are they aren't backed up by
any significant body of evidence confirming user desire and willingness to
create it.   Sure, the existing specs for RSS are ambiguous about so
counting usage within it could certainly be called into question.  But given
the state of tools and silly 'metacrap' arguments it continues to look
highly unlikely that users will put ANY effort into marking up TITLE
elements.  This balanced against the hassles it puts upon parsing tools
consuming the feeds makes arguing for support of markup in titles look like
a collosal waste of effort.

I'm all for content being as rich as people feel the need to torment
themselves into creating.  Just not as titles intended for use in feed-like
documents.

-Bill Kearney

----- Original Message ----- 
From: "Eric Scheid" <[email-masked]>

---

From: "jt" <[email-masked]>
Date: Sat, 11 Sep 2004 09:26:23 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Bill Kearney
| Sent: Saturday, September 11, 2004 8:52 AM
| To: Eric Scheid; 'Atom Syntax'
| Subject: Re: Summary of non-text-only uses of atom:title

<snip valid point made in childish fashion>

|  But given
| the state of tools and silly 'metacrap' arguments it continues to look
| highly unlikely that users will put ANY effort into marking up TITLE
| elements.

I looks that way because you WANT to see it that way, no doubt (in my mind).
The problem, others might note, is that it REQUIRES ANY effort to formatta
title.  Fix that bug, then you (some, most or all) might see things
differently.

| This balanced against the hassles it puts upon parsing tools
| consuming the feeds makes arguing for support of markup in titles
| look like
| a collosal waste of effort.

"Balanced against"...?  Dunno.  The <content> point Danny Ayers made??

| I'm all for content being as rich as people feel the need to torment
| themselves into creating.  Just not as titles intended for use in
| feed-like
| documents.

If you feel people are tormenting themselves by creating rich titles, then I
am highly dubious to trust the rest of your statement in this sentence.
Your statement of the intended use for titles is obvious non-factual.  That
would be YOUR intended use of titles.  YOUR interest is Synidcat8ing feeds,
but there are people at both ends 'of the wire' you appear to be forgetting.

---

From: Antone Roundy <[email-masked]>
Date: Sat, 11 Sep 2004 08:02:55 -0600

On Saturday, September 11, 2004, at 04:22  AM, Danny Ayers wrote:
> with in titles too.

Agreed.  You'd want a different whitelist of tags, attributes, CSS and 
whatnot to allow in titles vs. content, but it should come down to just 
one extra function call in the end.  In fact, even if the spec forbids 
markup, clients[1] are going to have to make that (or some other) 
function call anyway to ensure that nobody's sneaking malicious markup 
in where it's not supposed to go.

As long as we state that consumers MAY strip out markup (therefore, 
producers should put it in at their own risk), I don't see allowing 
markup causing pain.

[1] Clients whose display widget for titles doesn't interpret HTML 
would necessarily have to, but those that are affected by markup will.

---

From: "jt" <[email-masked]>
Date: Sat, 11 Sep 2004 10:34:23 -0400

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]]On Behalf Of Antone Roundy
| Sent: Saturday, September 11, 2004 10:03 AM
| To: [email-masked]
| Subject: Re: Summary of non-text-only uses of atom:title

Despite prior history, I'm 'obligated' to agree with Antone Roundy in this
regard.

| In fact, even if the spec forbids
| markup, clients[1] are going to have to make that (or some other)
| function call anyway to ensure that nobody's sneaking malicious markup
| in where it's not supposed to go.

This is what I thought, but didn't know for certain.  So **ALL THIS**
DISCUSSION/argument/bile would be about what again??  Boils down to what,
all the man-hours?

(Or is it mainly about sharpening political skewers?)

It's a WHOLE HECKUVA LOT EASIER to just strip everything (out of a title..
only...)...??  THE HORROR!!  I presume this is child's play to you guys, but
I've been wrong too many times to ass-u-me perhaps.

| As long as we state that consumers MAY strip out markup (therefore,
| producers should put it in at their own risk), I don't see allowing
| markup causing pain.

Or, im(ns)ho, extend the concept of profiles I 'heard' expressed here a
while back.

Radio button for receiver-users to select well-defined notions of
(C)onservative (M)oderate or (L)iberal acceptance of markup in Title, and/or
same for Content and/or elsewhere I'm not aware of.  Sender-users, by
definition, still have the option to send whichever they prefer to send
(including not respecting ANYthing in the spec, in reality).

Mebbe should include an option for Liber-(con)-trarian, which accepts
ANYTHING AND EVERYTHING UNDER ALL CIRCUMSTANCES, if it's in the mood...?!?
;-)  Who knows when somebody will have a "need" to imbed an MPEG in a title,
right!?!  ;-D

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 12 Sep 2004 01:57:50 +0200

> specifically not write "XHTML"?

I would guess that it's related to the JavaScript comments prefixing CDATA  
section needed to embed script in XHTML as well as comments for legacy  
clients without <script>-support. E.g. both:

   <script ...><!--

   //--></script>

and

   <script ...>
   //<[CDATA[
   //]]>
   </script>

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