不都合な木構造

表示リンクというのは、エレメントどおしの親子関係を表します。
BSやPLは項目（エレメント）が単純なツリー構造になっていますが、表示リンクはそのツリーの構成を定義しています。

例えば、BSの場合には、資産の部だけ抜き出すと以下のような構成になっています。

 + 貸借対照表
   + 資産の部
     + 流動資産
       + 現金・預金
       + 売掛金
     + 固定資産
       + 建物
     + 資産の部合計

上記のようなツリー構造を表示リンクでは以下のように表現します。

  from            to           order
貸借対照表 --> 資産の部         1.0
資産の部   --> 流動資産         1.0
資産の部   --> 固定資産         2.0
資産の部   --> 資産の部合計     3.0
流動資産   --> 現金・預金       1.0
流動資産   --> 売掛金           2.0
固定資産   --> 建物             1.0

あたかもリレーショナルデータベースに格納するかのように、ばらばらにして表現されています。
この１つ１つをアークと呼びます。

アークには、orderという属性があり、それが兄弟項目（この例では、「流動資産」「固定資産」「資産の部合計」が３兄弟、「現金・預金」「売掛金」が２兄弟になる）の順番を表します。

ここまでが基本的な表示リンクの考え方です。

簡単ですね。とても美しいし、シンプルだと思いませんか。

私は思いません。

XBRLのリンクはそんなに単純じゃなかったんです。

まず、次のような表示リンクが定義されていたらどうでしょうか。

  from            to           order
貸借対照表   --> 資産の部         1.0
資産の部     --> 流動資産         1.0
資産の部     --> 固定資産         2.0
資産の部     --> 資産の部合計     3.0
流動資産     --> 現金・預金       1.0
流動資産     --> 売掛金           2.0
固定資産     --> 建物             1.0
資産の部合計 --> 資産の部         1.0

「資産の部合計」が「資産の部」を生みました。この場合、貸借対照表からたどると、

貸借対照表 -> 資産の部 -> 資産の部合計 -> 資産の部 -> 資産の部合計 -> ・・・

と循環します。これでは、いくらメモリとCPUがあっても処理が終わりません。
よってこのような表示リンクは作ってはいけないことになっています。こういうのがあったら、処理系が検知しなきゃいけないのだそうです。なんだかなー、ですよね。

では、循環していない次のような表示リンクはどうでしょうか。

  from            to           order
貸借対照表   --> 資産の部         1.0
資産の部     --> 流動資産         1.0
資産の部     --> 固定資産         2.0   use="prohibited"
資産の部     --> 資産の部合計     3.0
流動資産     --> 現金・預金       1.0
流動資産     --> 売掛金           2.0
固定資産     --> 建物             1.0

use="prohibited"とは、禁止関係といってそのアークを無効にします。結果、固定資産が資産の部から独立し、貸借対照表がルートのツリーと、固定資産がルートのツリーができてしまいました。

 + 貸借対照表
   + 資産の部
     + 流動資産
       + 現金・預金
       + 売掛金
     + 資産の部合計

 + 固定資産
   + 建物

こっちはXBRL的に完全に有効な定義なのです。貸借対照表一族と、脱藩した固定資産一族、どちらがえらいか（先に出力すればよいか）はだれにもわかりません。未定義です。

アークは集まってグループ（ロールといいます）を構成し、各ロールで１つのツリーがきれいに出来上がるのが普通です。ルートが複数あるロールを正しいとする理由がわかりません。循環がNGなように、ルートが複数あるのもNGとすべきだと思います。

このようなおかしなツリーを構成してしまっている有報は、これまでにEDINETに提出されたものから見つけることができます。
例えば、2009年1月14日に開示された「株式会社サイゼリヤ」（安くておいしい）の四半期報告書がそれに該当します。これは、３ヵ月後の4/14に訂正報告書が出されています。
そのほかにもいくつか把握しているのですが、訂正されていないのでここでは名前は伏せておきます。

現在のEDINET/TDnetのXBRLデータの中には、XBRLの仕様どおりであっても「正しいとはいえないもの」「ガイドラインに反しているもの」というのが存在しています。

私も気づいたベースで提出者に連絡し、実際訂正していただいたケースもあります。（無視されたケースもありますが。）

ですが１個人１企業だけでやるには限界もあります。XBRLの利用者・提出者や提出者を支援する印刷会社などが協力して、XBRLで開示されるデータの質を高めていく必要があるのではないでしょうか。例えば、利用者が気がついたらすぐに提出者や印刷会社にフィードバックできるようなスキームを作るだけでも、迅速に訂正報告が出されるようになるだろうな、と思うわけです。