Brian Smith wrote:
[snip]
I think it makes more sense to get people to get some working
implementations that have informally agreed on some extensions,
I implemented extended bidi support in Apache Abdera months ago; and our
internal blogging environment supports bidi entries.
[snip]
How much of a problem is BIDI in Atom today? (This isn't a rhetorical question).
It's a problem. Quite a few readers I have tested do not even properly
support bidi markup used in entry title's that use (x)html and there are
language-sensitive attributes in the Atom schema that cannot use the
existing markup oriented solutions at all; and since the values for
those attributes are typically provided by humans, relying on the
software to properly insert the unicode formatting codes (which aren't
recommended for markup in the first place) is problematic at best.
Fortunately, there are ways of guessing the text direction with fairly
decent accuracy given the value of xml:lang. That is, the language or
script identified could be RTL. However, it's not always clear and
guessing is not always accurate. The bidi attribute gives us a good,
explicit fallback.
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.
What are you basing that on? There's really not much guess work
involved in the implementation and apps that choose not to implement
support will be no worse or better off than they are currently.
Most Atom constructs that hold human-readable text allow for XHTML, which
has its own BIDI mechanism. The main problem seems to be with person
constructs, and with extension elements. The Atom BIDI draft doesn't solve
the internationalization problems with person constructs because it doesn't
provide a way to do Ruby text markup, which is especially important for atom:name.
Don't forget atom:link/@title and atom:category/@label.
atom:category/@term can also cause problems when implementation use that
value for display purposes. Arbitrary extension elements can also have
problems.
The bidi draft doesn't attempt to solve all the i18n issues with Atom.
Ruby text is a problem for pretty much everything, especially given the
fact that most browsers don't have a clue how to properly render ruby
text yet. The bidi draft rightfully focuses on one small part of the
problem.
It also doesn't solve the problem with atom:link/@title or other attributes that
are language-sensitive.
Yes, it does.
- James
