James M Snell wrote:
> Recent discussions around tombstones, the Atompub Features 
> draft, and other extensions have revealed an apparent need 
> for some level of formal review for I-D's intended for the 
> Standards Track.  After discussing the subject with Lisa 
> Dusseault (the Area director), I believe that real progress 
> on these extensions can only be made within the context of a 
> formal IETF WG.  Therefore, I am proposing the creation of an 
> "Atom Extensions" (atomext) WG that will be chartered to 
> review and publish Standards Track extensions and revisions 
> to the Atom format and publishing protocol.  A draft charter 
> is provided below.

I think it makes more sense to get people to get some working implementations 
that have informally agreed on some extensions, and then bring those 
psuedo-standards to the IETF for standardization. Honestly, though, I'm not 
really sure what benefit that IETF provides over informal agreement between 
mailing list members. 

> The WG will initially focus on the review of existing 
> proposals for standards track extensions including:
> 
>  * Atom Bidi Extension, draft-snell-atompub-bidi-05

How much of a problem is BIDI in Atom today? (This isn't a rhetorical 
question). 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. 

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. It 
also doesn't solve the problem with atom:link/@title or other attributes that 
are language-sensitive. We should have a guideline that says that every 
extension element that contains human-readable text should be an atom text 
construct--i.e. that is should support XHTML markup, and the BIDI and Ruby 
subsets of XHTML in particular. And, the specification for atom:name and other 
existing language-sensitive elements should be updated so that they meet this 
guideline.

- Brian


Reply via email to