Subject: Re: Atom Bidi Draft Last Call

From: Nicolas Krebs <[email-masked]>
Date: Mon, 14 Apr 2008 22:56:51 +0200

>Date: Fri, 11 Apr 2008 11:47:55 -0700
>From: James M Snell <[email-masked]>
>To: atom-syntax <[email-masked]>
>Subject: Atom Bidi Draft Last Call

>The Atom Bidi draft [1] has entered last call.  I posted an updated 
>version of the draft today indicating "Experimental" status rather than 
>"Standards Track".  The draft is currently implemented by Apache Abdera 
>and the Lotus Connections Blogs component.  Additional implementation 
>and feedback are requested.
>
>- James
>
>[1] http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-06.txt

i.e.
urn:ietf:id:draft-snell-atompub-bidi-06
http://tools.ietf.org/html/draft-snell-atompub-bidi-06

Editorial comments. You could add 
- http://www.w3.org/TR/2007/REC-its-20070403/#directionality as 
informative references, in Section 5.2 
http://tools.ietf.org/html/draft-snell-atompub-bidi-06#section-5.2
- Why create atom:dir instead of re-use its:dir (in a Rationale section). 
- What are the differences between atom:dir and its:dir . 

others references/see also
- the various discussions (including 
http://www.imc.org/atom-syntax/mail-archive/msg04474.html 
http://bitworking.org/news/Not_Invented_Here ) wich leaded/caused 
urn:ietf:rfc:4287 http://tools.ietf.org/html/rfc4287 to: 
  - create its own xml elements atom:author, atom:published, 
  atom:summary, and do not re-use dc: elements
  - do not create its own lang attribute and allow xml:dir
- my previous mail about this subject/topic 
http://lists.w3.org/Archives/Public/www-international/2006OctDec/0003.html 
http://lists.w3.org/Archives/Public/www-international/2007AprJun/0017.html 
- http://www.w3.org/blog/International/2008/03/26/internationalization_tag_set_interest_gr
http://www.w3.org/International/its/ig/

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 14 Apr 2008 21:27:47 -0700

Nicolas Krebs wrote:
> James Snell wrote:
> >version of the draft today indicating "Experimental" status 
> > rather than "Standards Track".  The draft is currently implemented
> > by Apache Abdera and the Lotus Connections Blogs component.
> > Additional implementation and feedback are requested.

James,

Do you know of any publically-available Atom documents in BIDI languages
that would benefit from this extension? The example in the draft does
not seem to benefit from the extension; AFAICT, the text in the examples
is comprised of pure Arabic text, which is strongly RTL, so the Unicode
BIDI algorithm should work fine. I searched for some before, and I found
a few Hebrew and one Arabic Atom document, but none of them would have
benefited from this extension, AFAICT.

> - What are the differences between atom:dir and its:dir . 

I agree, these are the first questions I had when reading the previous
drafts.

The draft says 'Implementers are reminded that unexpected results could
occur when using both the "dir" attribute and the Unicode control
characters within a single document.' What are the expected results?

Regards,
Brian

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Apr 2008 21:13:52 -0700

Nicolas Krebs wrote:
> [snip]

There's no reason to introduce the added complexity of ITS here.  I 
recognize that it's not a lot of added complexity, but ITS would add the 
need to support another new namespace and new MUST-level requirements 
that simply aren't needed.  Further, Atom bidi does not need the rlo and 
lro values to indicate bidi overrides and ITS does not provide a means 
of explicitly indicating that no base directionality has been set (e.g. 
dir="") which is an important case for feeds aggregating content from 
multiple sources.

- James

---

From: James M Snell <[email-masked]>
Date: Tue, 15 Apr 2008 21:16:31 -0700

I know of several feeds that could benefit from this but there's 
certainly not an extensive collection, currently... which is precisely 
why this is targeted for "Experimental" status rather than "Standards 
Track".  The idea is to get a stable specification out there and 
encourage folks to go forth and implement it.  As we learn more about 
internationalization issues in feeds, we can revisit this.  Experimental 
RFC's are a good thing :-)

- James

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 16 Apr 2008 05:43:53 -0700

James M Snell wrote:
> certainly not an extensive collection, currently... which is 
> precisely why this is targeted for "Experimental" status
> rather than "Standards Track".  The idea is to get a stable
> specification out there and encourage folks to go forth
> and implement it.  As we learn more about internationalization
> issues in feeds, we can revisit this. Experimental RFC's are
> a good thing :-)

James,

Thanks for the reply. I was not trying to say "this sucks because nobody
needs it." I was saying that there are literally no examples available
that show how it is beneficial. Even the examples do not demonstrate the
usefulness of the mechanism; they use dir="rtl", but they would be
rendered the same even if the mechanism wasn't being used, because the
example BIDI text is 100% strongly RTL, right?

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 16 Apr 2008 06:30:29 -0700

James M Snell wrote:
> There's no reason to introduce the added complexity of ITS here.
> I recognize that it's not a lot of added complexity, but ITS 
> would add the need to support another new namespace and new

The new namespace actually solves a real problem with extension
elements:

  <entry xmlns='http://www.w3.org/2005/Atom'
         xmlns:a='urn:foo:a'
         xmlns:b='urn:foo:b'>
     <a:x dir='RTL'>
         <b:x dir='LTR'/>
     </a:x>
     ...
  </entry>

How do you process the above document using the BIDI extension? It seems
that either the Atom BIDI extension cannot be used with extension
elements, or it reserves the "dir" attribute for every element in every
namespace. Reserving the "dir" attribute for every element in every
namespace is not realistic. If the Atom BIDI extension cannot be used
with extension elements, then we have to fall back to ITS for extension
elements.

> MUST-level requirements that simply aren't needed.

Assuming only local selection is to be supported, the only annoying
MUST-level requirement is that its:version must be present on the root
element of the document. Is there another requirement that you think it
troublesome.

> Further, Atom bidi does not need 
> the rlo and lro values to indicate bidi overrides

My understanding is that RLO and LRO are used in documents that describe
BIDI, so that those documents can provide examples of mis-renderings. I
don't know if there are other realistic uses of it. In any case, an Atom
processor already has to deal with RLO and LRO anyway, to support BDO in
(X)HTML.

> and ITS does not provide a means of explicitly indicating that no
> base directionality has been set (e.g. dir="") which is an
> important case for feeds aggregating content from multiple sources.

I don't think this is a problem. The producer of the aggregate feed just
has to be careful to not use its:dir in the atom:feed element (instead,
each feed metadata element can have its own its:dir as necessary), and
to copy the its:dir from the source feeds into each entry it extracts
from them (unless that entry already has its own its:dir). It is just
slightly different from the processing of the Atom BIDI extension.

Cheers,
Brian

---

From: James M Snell <[email-masked]>
Date: Wed, 16 Apr 2008 07:16:26 -0700

> with extension elements, then we have to fall back to ITS for extension

It doesn't reserve the dir attribute in every namespace. The dir 
attribute has no namespace and there's little difference between it and 
the type attribute on the Atom Text Construct.

RFC 4287 defines the Atom Text Construct as an abstract type.  Within 
that element, there is a type attribute.  I can define that element 
x:foo is a text construct such that <x:foo 
type="html">&lt;p&gt;bar&lt;/p&gt;</x:foo> is a perfectly legal construct.

- James

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 16 Apr 2008 08:20:18 -0700

James Snell wrote:
> attribute has no namespace and there's little difference 
> between it and the type attribute on the Atom Text Construct.
> 

Of course. My point is that an extension cannot fully support the Atom
BIDI extension if it uses the "dir" attribute for some other purpose.
Further, an Atom processor cannot process the Atom BIDI extension for
extension elements that it has no knowledge of, because it has no way of
knowing what the "dir" attribute means for unknown extension elements.
ITS avoids those problems by defining better namespace support.

Regards,
Brian

---

From: Joe Cheng <[email-masked]>
Date: Thu, 17 Apr 2008 16:44:26 -0700

> ...they use dir="rtl", but they would be

Doesn't dir="rtl" generally result in blocks being right-aligned instead
of left-aligned? At least this is the case in HTML.

(Sorry if I am way off, I'm not an expert in bidi and haven't been
following the thread)

---

From: "Brian Smith" <[email-masked]>
Date: Sun, 20 Apr 2008 17:08:22 -0700

Joe Cheng wrote:
> Doesn't dir="rtl" generally result in blocks being 
> right-aligned instead of left-aligned? At least this
> is the case in HTML.
> 

Possibly. I bet James would be able to answer better than me. I would
think that the default alignment would depend heavily on the user
interface of the application and the user's language preferences.

My understanding is that directionality overrides are primarily focused
on the correct rendering of characters that are not stringly LTR or RTL,
like punctionation, when they appear between strongly LTR and strongly
RTL letters. The W3C ITS recommendation has a few examples in its test
suite that demonstrate its BIDI overrides, and those examples all deal
with punctuation between English and Arabic text.

- Brian

---

From: James M Snell <[email-masked]>
Date: Sun, 20 Apr 2008 18:25:32 -0700

The display details can vary broadly depending on the application and 
the context.  Feed readers are diverse enough that it simply does not 
make much sense for the bidi draft to specify any requirements as far as 
alignment is concerned or even appropriate levels of embedding.  The 
most the spec says about alignment is that implementers MAY use the same 
alignment rules as HTML but no requirements are specified.

- James