Re: Atom Bidi Draft Last Call

Brian Smith wrote:
> 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.
> 

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

>> 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 14:17:17 UTC