RE: Atom Bidi Draft Last Call

James M Snell wrote:
> Nicolas Krebs wrote:
> > 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 . 
> > 
> 
> 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

Received on Wednesday, 16 April 2008 13:31:12 UTC