xml:langという属性はXSL-FOからすると結構重要な属性です．例えば、とかく漢字は日本語を書いていると日本語フォントが選択されて当然と考えられるかもしれませんが、中国、台湾でも漢字はあたりまえに使われますし、ほとんど使われなくなってきているとはいえ、韓国でも漢字は人の名前に使われます．つまりUnicodeのCJK Ideographic（CJK統合漢字）は、その文字コードだけでは日本語フォントを当てはめるのか？中国語フォントを当てはめるのかはあいまいなのです．しかしxml:lang="ja-JP"をそのブロック（fo:block）に指定してあげさえすれば、適切に日本語フォントが選択されるでしょう．もちろん漢字といっても、簡体字のようにあきらかに中国本土でしか使用されないものもありますし、例えば「畑」なんていう漢字は実は日本製で、中国へ渡ったというものもあって成り立ちは一様ではありませんが．
しかしDITAのPDFの世界ではxml:langはあまり重要視されていなかったように思えます．それは、標準のPDF2プラグインが、ルートマップのxml:langのみを見て基本的な言語を判定している処理になっており、また少し前からはなくなりましたが、Unicodeの文字コードからフォントを選択するという（とんでもない）処理をやっていたからです．（これは2000年代の初めのIdiom Technologiesという現在ではSDLに買収された会社がこのプラグインの原型を作ったのですが、その当時からこのような処理が行われていたからにほかなりません．）
また、DITA-OTの処理も確かDITA-OT 1.8Xくらいからだったと思うのですが、個々のトピックにxml:langが指定されていなければ、デフォルトでen-USがつけられてしまうという、これもとんでもない処理でxml:langが扱われていました．
日本語でDITAのインスタンスを作るとき、個々のトピックにxml:langを必ず書くでしょうか？CMSを使用して言語展開している場合は厳格にCMSがxml:langを管理しますので、翻訳の過程で自動的につけてくれるはずです．しかしCMSをつかわずに手作業でいくつものトピックをつくっている場合、まずxml:langは書かないと思います．たぶんルートマップのxml:langをつければOKじゃないか？と考えるでしょう．
実は多言語の混在するようなトピックを処理できるように、PDFのプラグインを開発していた際、ルートマップにxml:lang="ja-JP"と書いても、個々のトピックを処理して中間ファイルに出すと、とたんにxml:lang="en-US"に一律になってしまってビックリしました．このような場合、少なくともルートマップのxml:langを尊重するか、せめて何も初期値を設定してほしくなかったのですが、今度のDITA-OT 2.3でようやくこのお願いをかなえていただくことができました．
TopicMerge sets unexpected @xml:lang attribute to topic.
現在最新のDITA-OT 2.3で試してみると、topic/@xml:langがない場合、topic/@xml:langには何も付かない仕様になっているようです．しかしこの障害報告を私がGitHubに出したのは2013年の3月です．足掛け3年でようやく実現してもらったことになります．なかなかDITA-OTのような世界的に使われているツールに仕様変更のようなものをお願いして開発者に理解していただき、直してもらうのは容易ではありません．ましてや英語で書かねばならず、ネイティブでない私が説得力のある文章を書くのはとても無理です．
実のところ本業の仕事が忙しいのでissueに出していないのですが、DITA-OTで直してもらいたい点はまだまだあります．恥をかきながらでも良いので、なんとかリクエストを出すのは継続しようと思います．
