Could you *please* correct the text around Listing 3? You are making the same mistake that several popular aggregators have already made, thinking that Atom text constructs are like RSS, where you have to make your best guess about whether the content of an element is escaped HTML or not.
Listing 3 doesn't violate the spirit of the spec, it *is* the spirit: it is plain text, and the character entity references for less-than and greater-than should be displayed as unreplaced character entity references. It is an example of HTML source, and if you and aggregators persist in claiming that it *is* HTML source, rather than an example, then there will be absolutely no way to use the less-than character in type="text".
There is nothing to "fix". We apparently just disagree.
If you were to display the title of a feed as in listing 3 using your "text is text" philosophy (I think that especially in the age of markup languages this is a huge oversimplication) you would basically have Grandma May User staring at a mess of greater than and less than signs with words that have no grammatical reason for being there.
The spirit of the spec is that a text construct is intended for human reading. Unmarked, escaped tags are not intended for human reading. Sure there are cases where ampersands and less than signs appear in text that *is* meant for human reading, and I have no problem with the escaping in such cases.
As for listing 3, it is a silly thing to do and an unnecessary thing (you can fix it by just using "type="html" or better yet "type="xhtml") so I stand by my admonition for developers to avoid it.
No one said that anyone should decode a text construct of type text. My point is precisely that it should not be decoded in any way. And as I said in the introduction to the article Atom's purpose is indeed to remove such ambiguity. So I don't understand why you want to reintroduce the ambiguity by sneaking in text. If you want to embed markup, say so in your Atom file. That's what the type attribute is for.
And all specs have a spirit. All formal communication has a spirit. It's a consequence of the fact that no human communication is unambiguous. A practical manifestation of the spirit of Atom is the fact that the Atom validator issues warnings. Such a warning can be thought of as something that violates the spirit rather than the letter of a spec.
If you have different advice to offer people with regard to type="text", you are entitled. I never told anyone markup in type="text" is illegal. I merely offered my advice to avoid the practice. I stand by that advice.
Certainly, avoiding markup in type="text" is good advice, but it should be good advice "because your markup will be displayed rather than being interpreted" rather than "because it's the wrong thing to to do." Having misstated my position and put it too strongly, I don't expect to persuade you at this point, but I do still believe that this puts type="text" in exactly the same position as title in RSS: you simply cannot use a less-than character in it with any hope of it being correctly interpreted.
OK. I think this means that we don't disagree as strongly as it first seemed, but that you think I wasn't clear enough in the article itself on the reasons for avoiding embedded markup in type="text". I can accept that. I felt that my discussion and references elsewhere in the article on the subject of escaped markup would make the reasons for my advice reasonably clear, but I was probably too laconic in the text immediately leading up to listing 3. If so, I hope this thread helps tease out the matter sufficiently for readers.
Yeah, not so much, Uche -- I can't say I agree with your interpretation at all. First, there's really no "spirit" of the spec; the Atom spec is very overt when it explains that text is for literal display of text, and even uses an example that demonstrates that an ampersand-encoded less-than sign should remain as such. Second, your assumption that "unmarked, escaped tags are not meant for human reading" is a bit presumptuous -- they're certainly meant for reading in many given contexts, like in programming, data streams, and the like. One of the largest purposes of Atom -- you can read this over and over in the discussions that happened right out in the open -- is to take away the ambiguity of situations like this by providing explicit types that content providers can specify, and then telling Atom consumers that they must abide by those types if they wish to faithfully represent the content. If a <title> with a type of text has an escaped less-than sign in it, then the Atom consumer must not decode it; anything less is making an assumption that's just plain wrong.
Previous Message
