Subject: Re: [atom-syntax] Atom bidi

From: Nicolas Krebs <[email-masked]>
Date: Tue, 17 Oct 2006 15:05:02 +0200

To: [email-masked], [email-masked]
Copy to: [email-masked]

James Snell wrote in http://www.imc.org/atom-syntax/mail-archive/msg18925.html

> To: atom-syntax [email-masked]
> Subject: Atom bidi
> From: James M Snell <[email-masked]
> Date: Fri, 13 Oct 2006 13:20:28 -0700

> As an alternative to adding the dir attribute to rfc4287, I've published
> draft-snell-atompub-bidi-00.txt as an extension in a separate namespace.
> 
> As always, feedback is requested and welcome.
> 
> - James
> 
> -------- Original Message --------
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
> 	Title		: Atom Bidirectional Extension
> 	Author(s)	: J. Snell
> 	Filename	: draft-snell-atompub-bidi-00.txt
> 	Pages		: 8
> 	Date		: 2006-10-13
> 	
>    This document describes an extension to the Atom format that can be
>    used to define the base directionality of directionally-neutral
>    characters contained within an Atom document.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-snell-atompub-bidi-00.txt
> 

The goal and the draft seem good to me. 

There are at least 4 specifications to define the directionality of text 
in xml format:  

specification: Atom Bidirectional Extension
URI: urn:ietf:id:draft-snell-atompub-bidi urn:ietf:id:draft-snell-atompub-bidi-00 
http://tools.ietf.org/id/draft-snell-atompub-bidi*
attribute: dir
values: ltr, rtl, lro, rlo
xml namespace: http://purl.org/atompub/bidi
status: working draft

specification: XHTML 1.0
URI: http://www.w3.org/TR/xhtml1 http://www.w3.org/TR/2002/REC-xhtml1-20020801
attribute: dir
values: ltr, rtl
xml namespace: http://www.w3.org/1999/xhtml
status: usable

specification: XHTML 2.0
URI: http://www.w3.org/TR/xhtml2/mod-bidi.html#adef_bidi_dir http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-bidi.html#adef_bidi_dir
attribute: dir
values: ltr, rtl, lro, rlo
xml namespace: http://www.w3.org/2002/06/xhtml2/ 
status: working draft

specification: Internationalization Tag Set 1.0
URI: http://www.w3.org/TR/its/#dir-sec http://www.w3.org/TR/2006/WD-its-20060518/#dir-sec
attribute: dir
values: ltr, rtl, lro, rlo
xml namespace: http://www.w3.org/2005/11/its
status: working draft
editor: W3C Internationalization Tag Set working group http://www.w3.org/International/its/

XHTML 1.0 is the only specification which is not a working draft, but its 
dir attribute does not allow "lro" and "rlo" values. 

I do not guess XHTML 2.0 will be usable before a long time. 

What are the roadmap for "Atom Bidirectional Extension" and 
"Internationalization Tag Set 1.0" ? On the today speed, when are they 
sheduled, when can we hope, that it will be internet^W xml standard and 
published as "W3C Recommendation" or "IETF RFC" ? 

Could it be avoided having two spec for the same purpose ? 

See also 
- Richard Ishida, "What you need to know about the bidi algorithm and inline 
markup", http://www.w3.org/International/articles/inline-bidi-markup/
- W3C Internationalization Tag Set working group, "Best Practices for XML 
Internationalization", section 2.2 "Provide a way to specify text directionality", 
http://www.w3.org/TR/xml-i18n-bp/#DevDir
- James Snell, "Adding bidi support to Atom", http://www.snellspace.com/wp/?p=470
- James Snell, "Atom Bidirectional Extension", http://www.snellspace.com/wp/?p=484
- "PaceAtomBidi", http://www.intertwingly.net/wiki/pie/PaceAtomBidi
- "FAQ: Bidi formatting codes vs. markup in (X)HTML", 
http://www.w3.org/International/questions/qa-bidi-controls
- "FAQ: CSS vs. markup for bidi support", 
http://www.w3.org/International/questions/qa-bidi-css-markup

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 08:15:10 -0700

The key challenge with using ITS in Atom is its complexity and scope.
Atom simply doesn't need to do that much.

- James

Nicolas Krebs wrote:
> [snip]

---

From: "James Holderness" <[email-masked]>
Date: Tue, 17 Oct 2006 17:07:44 +0100

If you're going to require a separate namespace for bidi support, maybe it's 
best to use XHTML 1.0 and just toss out the lro and rlo values. I know I was 
originally pushing for those to be included, but now that I've seen how 
inconsistent the bdo support is in browsers I think they're probably going 
to be a waste of time. Nobody is going to get them right.

Regards
James

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Oct 2006 12:43:49 -0400

fwiw, I have no intention of reading the Snell bidi draft, or 
implementing what might be inside. As I've mentioned several times, I am 
already implementing a solution. I will document it and roll it onto the 
standards track as an update to RFC4287.

-Rob

James Holderness wrote:
>
> If you're going to require a separate namespace for bidi support, 
> maybe it's best to use XHTML 1.0 and just toss out the lro and rlo 
> values. I know I was originally pushing for those to be included, but 
> now that I've seen how inconsistent the bdo support is in browsers I 
> think they're probably going to be a waste of time. Nobody is going to 
> get them right.
>
> Regards
> James
>

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 09:52:45 -0700

That's certainly a strong option.

- James

James Holderness wrote:
> 
> If you're going to require a separate namespace for bidi support, maybe
> it's best to use XHTML 1.0 and just toss out the lro and rlo values. I
> know I was originally pushing for those to be included, but now that
> I've seen how inconsistent the bdo support is in browsers I think
> they're probably going to be a waste of time. Nobody is going to get
> them right.
> 
> Regards
> James
> 
>

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Oct 2006 13:03:52 -0400

James M Snell wrote:
> How kind of you.  Would you mind sharing some of the details with us now
> so that we can come to a common solution that works with more than just
> Firefox and Thunderbird?  
It'll work fine with everythign

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 10:03:02 -0700

How kind of you.  Would you mind sharing some of the details with us now
so that we can come to a common solution that works with more than just
Firefox and Thunderbird?  I really can't imagine that it would all that
different than what I've documented and it would be silly to come up
with an alternative solution simply because you don't like the author.

- James

Robert Sayre wrote:
> 
> I will document it and roll it onto the standards track as an update to RFC4287.
> [snip]

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 10:14:50 -0700

> It'll work fine with everythign

Would you mind sharing some details? Is there code already in the
mozilla CVS I can go look at?  I have some code already written that I'd
like to get checked into Abdera soon.  I'd prefer that it match what
other implementors are doing or are planning to do.

I personally don't mind who writes up the spec or whether it's done as
an update to 4287 or not.  Nor do I really care whose name ends up on
the draft.  Heck, we could probably even collaborate on the draft.  Take
what I've started with, make whatever changes you feel are necessary and
add your name to the author list.  I've attached the XML.

- James
<?xml version="1.0"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc4287 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml'>
    <!ENTITY xmlnames PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-names-19990114.xml'>
    <!ENTITY infoset PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-xml-infoset-20040204.xml'>
]>

<rfc category="std" ipr="full3978" docName="draft-snell-atompub-bidi-00.txt">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<front>
<title abbrev="Atom Bidi">Atom Bidirectional Extension</title>
<author initials="J.M." surname="Snell" fullname="James M Snell">
<organization />
<address>
<email>[email-masked]</email>
<uri>http://www.snellspace.com</uri>
</address>
</author>
<date month="September" year="2006" />
<area>General</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>IRI</keyword>
<keyword>URI</keyword>
<keyword>Template</keyword>

<abstract><t>This document describes an extension to the Atom format
that can be used to define the base directionality of directionally-neutral characters 
contained within an Atom document.</t></abstract>
</front>
<middle>

<section title="Introduction">

<t>This document describes an extension to the Atom format <xref target="RFC4287" />
that can be used to define the base directionality of directionally-neutral characters 
contained within an Atom document.</t>

<section title="Namespace">

<t>The XML Namespaces URI <xref target="W3C.REC-xml-names-19990114" /> for the 
XML elements and attributes described in this specification is</t>
 
<figure><artwork><![CDATA[http://purl.org/atompub/bidi]]></artwork></figure>

<t>In this document, the namespace prefix "u:" is used for the above 
Namespace URI. Note that the choice of namespace prefix is arbitrary
and not semantically significant.</t>

</section>

<section title="Notational Conventions">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 
interpreted as described in BCP 14, <xref target="RFC2119" />.</t>

<t>This extension is, like the Atom Syndication Format <xref target="RFC4287" /> itself,
specified using terms from the XML Infoset <xref target="W3C.REC-xml-infoset-20040204"/>.
However, this specification uses a shorthand form for two commons terms:  
The phrase "Information Item" is omitted when naming Element and Attribute 
Information Items. Therefore, when this specification uses the term "element," 
it is referring to an Element Information Item in Infoset terms.  Likewise,
when it uses the term "attribute," it is referring to an Attribute Information Item.</t>

<t>Some sections of this specification are illustrated with fragments of a 
non-normative RELAX NG Compact schema <xref target="RELAXNG" />. However, the 
text of this specification provides the sole definition of conformance.</t>

</section>

</section>

<section anchor="dir" title="The &quot;u:dir&quot; Attribute">

<t>The "u:dir" attribute specifies the base direction of directionally-neutral 
text <xref target="UNICODE"/>.  Possible values for the attribute are "ltr" and "rtl" indicating 
"left-to-right" and "right-to-left" respectively, "lro" and "rlo" indicating 
explicit "left-to-right" and "right-to-left" overrides, or an empty string 
indicating that no base-direction is specified.  If the "u:dir" attribute is not 
specified, the value is assumed to be an empty string. The attribute can appear 
anywhere in an Atom document, except where it is explicitly forbidden.</t>

<figure><artwork><![CDATA[
  dir = attribute u:dir { "ltr" | "rtl" | "lro" | "rlo" | "" }
]]></artwork></figure>

<t>The direction specified by "u:dir" applies only to elements and attributes 
whose values are specified as being "Language-Sensitive" as defined by Section 2
of <xref target="RFC4287" />.  The attribute is inherited by descendent elements 
and may be overridden.</t>

<t>Example atom:feed with right-to-left directionality</t>

<figure><artwork><![CDATA[
  <?xml version="1.0" ?>
  <feed xmlns="http://www.w3.org/2005/Atom"
        xmlns:u="http://purl.org/atompub/bidi" u:dir="rtl">
    <title>&#x0679&#x067A;&#x067B;</title>
    ...
  </feed>
]]></artwork></figure>

<t>If an Atom document contains any right-to-left characters, the Unicode 
Bidirectional Algorithm <xref target="UNI9"/> MUST be used to render that text. Because 
consumers of Atom documents vary broadly in the way they display text, the 
"ltr" and "rtl" values do not necessarily open an additional level of embedding 
with respect to the bidirectional algorithm. Consuming applications that render 
bidirectional text are responsible for determining the appropriate level of 
embedding.</t> 

<t>The "lro" and "rlo" values override the inherent directionality of characters 
as defined by <xref target="UNICODE"/>.  When used, affected text MUST be rendered as if preceded 
by either Unicode character U+202D (left-to-right override) or U+202E (right-to-left
override) and followed by U+202C (pop directional formatting).</t>

<t>When Atom Text Constructs or the atom:content elements contain bidirectional 
text and the type attribute is set to either "html" or "xhtml", the bidirectional 
markup mechanisms specific to each format SHOULD be used.  The value of the "u:dir"
attribute does define the base directionality of Language-Sensitive text within 
Text Constructs and atom:content elements regardless of the value of the type 
attribute.</t>

<t>Example atom:feed with bidirectional XHTML:</t>

<figure><artwork><![CDATA[
  <?xml version="1.0" ?>
  <feed xmlns="http://www.w3.org/2005/Atom" 
        xmlns:u="http://purl.org/atompub/bidi" u:dir="rtl">
    <title type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p dir="rtl">&#x0679&#x067A;&#x067B;</p>
      </div>
    </title>
    ...
  </feed>
]]></artwork></figure>

<t>The Unicode bidirectional control characters MAY also be used within attributes 
and element values to indicate the directionality of text.  Implementers are 
reminded that unexpected results could occur when using both the "u:dir" attribute
and the Unicode control characters within a single document.</t>

</section>

<section anchor="security" title="Security Considerations">

<t>The security considerations discussed in <xref target="RFC4287" /> Section 8 apply.</t>

</section>

<section title="IANA Considerations">

<t>No IANA actions are required by this document.</t>

</section>

</middle>
<back>
<references title="Normative References">
  &rfc2119;
  &rfc4287;
  &xmlnames;
  &infoset;
<reference 
  anchor="UNICODE">
  <front>
    <title>ISO/IEC 10646:2003: Information Technology - Universal Multiple-Octet Coded Character Set (UCS)</title>
    <author>
      <organization>International Organization for Standardization</organization>
    </author>
    <date month="December" year="2003" />
  </front>
</reference>
<reference 
  anchor="UNI9">
  <front>
    <title>The Bidirectional Algorithm</title>
    <author initials="M" surname="Davis" fullname="M. Davis">
      <organization>International Organization for Standardization</organization>
    </author>
    <date month="March" year="2004" />
  </front>
</reference>
</references>
<references title="Informative References">
<reference 
  anchor="RELAXNG" 
  target="http://www.oasis-open.org/committees/relax-ng/compact-20021121.html">
  <front>
    <title>RELAX NG Compact Syntax</title>
    <author initials="J" surname="Clark" fullname="James Clark">
      <organization />
    </author>
    <date month="December" year="2001" />
  </front>
</reference>
</references>
<section title="Acknowledgements">
<t>TBD</t>
</section>
</back>
</rfc>

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Oct 2006 13:11:04 -0400

James M Snell wrote:
> Would you mind sharing some of the details with us now
That is absurd.

This message has used up my atom-syntax time for the moment, so I guess 
you'll have to wait, or use up other people's atom-syntax time.

-Rob

---

From: Robert Sayre <[email-masked]>
Date: Tue, 17 Oct 2006 14:09:52 -0400

Robert Sayre wrote:
> implementing what might be inside. As I've mentioned several times, I 
> am already implementing a solution. I will document it and roll it 
> onto the standards track as an update to RFC4287.
To be clear, I have no intention of ignoring input from this list, since 
that almost always results in improvements. I also have no intention of 
implementing anything that should have approval from the group, unless I 
have that approval. However, I don't think I'm obligated to let our more 
enthusiastic participants dictate the manner and pace of my personal 
contributions.

-Rob

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 12:32:46 -0700

I've modified my very preliminary impl to support the use of xhtml:dir
and have checked in some code [1].  The impl is very rough and designed
only to illustrate the basic behavior I have in mind.

Right now, the code determines the direction of text using the following
steps (in order):

 1. Look for an unprefixed "dir" attribute
 2. Look for the xhtml:dir attribute
 3. Look for any attribute with local-name="dir" and whose
    value looks appropriate (e.g. f:dir="ltr" xmlns:f="urn:foo" )
 4. If not found, iterate up through parent elements

- James

[1] http://tinyurl.com/ydb8uy

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 18 Oct 2006 01:07:27 +0200

>  2. Look for the xhtml:dir attribute

There's no such thing. (Except perhaps with this new XHTML Modularization  
madness, but that's best ignored.)

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 16:48:22 -0700

I know there's no such thing :-)... which is precisely why the code I
implemented is temporary and experimental :-).

- James

Anne van Kesteren wrote:
> There's no such thing. (Except perhaps with this new XHTML
> Modularization madness, but that's best ignored.)
> 
> 
> --Anne van Kesteren

---

From: "James Holderness" <[email-masked]>
Date: Wed, 18 Oct 2006 00:57:22 +0100

Well I'm glad somebody pointed it out because I certainly missed it. Anyway, 
for now I'm just checking for an unprefixed dir attribute. If and when RFC 
4287 is ever updated I'll ammend my code accordingly.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Oct 2006 17:16:39 -0700

Yeah, for now I'm going to keep this bidi code off in an out of the way
corner in the Abdera CVS until there's any more movement.  Now that I've
addressed a short term need I've had on my list for a while, I'll be
holding off at least a few weeks to see what Sayre comes up with before
deciding whether to update the I-D and I'll hold off making any further
updates to Abdera until after the WG makes a clear decision.

- James

James Holderness wrote:
> 
> Well I'm glad somebody pointed it out because I certainly missed it.
> Anyway, for now I'm just checking for an unprefixed dir attribute. If
> and when RFC 4287 is ever updated I'll ammend my code accordingly.
> 
> Regards
> James
> 
> James M Snell wrote: