David Powell wrote:
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.
This has been covered many times in the past. The xhtml mechanisms do
not help when we're dealing with bidi text in attributes like
atom:link/title and atom:category/label, the various plain text
elements, and extensions.
Second, when dealing with (x)html text and content, the specification
specifically recommends using the bidi mechanisms native to each.
Third, neither Unicode or the W3C recommend using the Unicode bidi
formatting codes are not recommended in markup, for a variety of
reasons. The fact that Atom will typically be created by software
doesn't solve the problem.
Fourth, even with the Unicode formatting codes, there are existing
deployed feed readers that get it wrong.
Fifth, the bidi attribute defined in the spec does not introduce any
additional interop issues. Client implementations that do not support
it will continue to act exactly as they do today. If intermediaries
drop the attribute on the floor, no critical data is lost and no
existing applications will be broken. I know this for a fact because I
have about 100k internal Atom feeds that are currently using the bidi
attribute and have been since May of last year.
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.
Again, existing bidi markup does not help us outside of (x)html text and
content elements.
The goal of this specification is to provide a means of indicating the
text direction without changing the way existing implementations work --
meaning that existing implementations that do not support the extension
will continue working as they always have while implementations that do
support the extension can realize it's benefits.
[snip]
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.
And how would that help us with atom:link/@title and atom:category/@label?
But to be honest, I'd like to see people knocking on our doors before we start
writing drafts to solve potential problems.
Ok, I'm knocking. This is not a potential problem. I implement and
support existing deployed software that publishes feeds with bidi text.
I've seen the rendering problems first hand. There's nothing potential
about it.
- James
