James M Snell wrote: > With this, I think it is important to look at both the > original intent of the spec and what clients are most likely > to support. While the schema is non-normative, the fact that > atom:name is clearly and specifically marked as "text" in the > schema makes the intent clear. You > *might* be able to stretch really far and claim that escaped > HTML is permitted, but if that was the intent, the spec would > more than likely say so.
I think "Atom allows foreign markup anywhere in an Atom document, except where it is explicitly forbidden" is explicit. I just tested Google Reader, IE7, RssBandit, FeedDeamon, and SharpReader. Of those, only SharpReader failed to strip out XHTML markup in an atom:name construct. I think changing atom:name to a text construct is something that could reasonably happen in a minor revision of RFC 4287, but I agree that currently it is not something that everybody should expect to work in every tool. > If you want the Person construct to contain ruby text, the > best approach would be to define an extension element > designed for the purpose of providing a "display" version of > the name, e.g. > > <author> > <name>name</name> > <x:display-name> > <ruby xmlns="http://www.w3.org/1999/xhtml";> > <rb>name</rb><rp>(</rp><rt>ruby</rt><rp>)</rp> > </ruby> > </x:display-name> > ... > </author> > > This would allow existing clients to continue to operate as > they always have. That seems reasonable. It also solves the problem of BIDI text in atom:name, and allows for using Microformats to distinguish between family names and given names. - Brian
