Brian Smith wrote:
>> The WG will initially focus on the review of existing >> proposals for standards track extensions including: >> >> * Atom Bidi Extension, draft-snell-atompub-bidi-05 > > How much of a problem is BIDI in Atom today? (This isn't a rhetorical > question). Atom documents are almost never hand-entered, and there is > already a specification in place for markup up BIDI and even ruby text > in general XML. The odds that clients and servers are going to > correctly implement this extension--except those targeted direclty > towards BIDI users--seem pretty low to me. Personally, it seems much > easier to implement the an existing BIDI markup mechanism (Unicode, > XML, and/or XHTML) than a new standard. I agree. We already have HTML - which supports much more internationalization features than just bidi. We also have Unicode bidi controls, for people who don't want to use HTML for whatever reason. Do we really need 3 different interacting implementations of bidi? This proposal will just cause interop problems when people try to use it with implementations that don't yet support it, when those people could probably have just used the HTML or Unicode techniques with more success. And isn't the purpose of bidi markup usually to clarify ambiguities that would arise from applying the Unicode bidi algorithms? To do that you need to be able to mark up the interior of these text-only elements, which this proposal wouldn't support anyway. As I mentioned in my previous email re: feed/entry metadata elements: Mixing feed and entry metadata is considered harmful (by me). This applies here too, because applying inheritable bidi attributes at <feed> level and expecting it to apply to the contained <entry> elements is something that can only be done if the implementation of the component that decouples feed elements and entry elements from a stateful feed is aware of it. And we shouldn't be designing extensions that require software to be updated everytime someone writes an Internet Draft in order that they don't corrupt people's data. If we really need support for Ruby and bidi in <atom:name>, and we aren't immediately intending to supercede RFC4287, I think we would be better adding an additional entry/person metadata element that supports HTML names. But to be honest, I'd like to see people knocking on our doors before we start writing drafts to solve potential problems. -- Dave
