法令XML文書化計画
舞台裏通信
第1号(2004-08-01)
読者からのメール
やはりwebmasterが思いつくようなことはとっくに誰かが考えているということで、法令のXML文書化は法情報学の対象として取り扱われているとのメールをいただいた。 ご教示に従い「法情報 XML」でぐぐったところ、下記の2サイトに代表される示唆に富む各種のリソースを見つけることができた。 改めて感謝の意を表したい。
上記2サイトに比べると断片的ではあるが、次のページも興味深い。
読者からのリンク
- 7月26日@圏外からのひとこと
- アドバイスに従い、今回よりマークアップの実例を本企画の一コーナーとして始めることとした。
- 7月26日@Propos
- 記事中、アメリカにおける同様の取り組み（ただしこちらは下院による公的プロジェクトで、スキーマもとっくに完成している）が紹介されているが、それを見ると本企画の意義が疑わしく思われ（和訳すればいいじゃないか、ということ）、しかしlinuxだって各種unixやウィンドウズ、マックより後で開発されてなお意義があったじゃないか、と思ってみたり。
- 7月26日@hyperashのLog Book
- 上記圏外からのひとことさん経由。 航空法を用いて早速マークアップを試していただいた。
- 7月27日@幾霜
- こちらも圏外からのひとことさん経由。
修正・訂正・変更レポート
- article要素の解説で、clause要素直下に条文の文言に係る文字データが置かれるように書いていたが、その子要素を設けてその中に文字データを入れるようにした方がよいように思えてきたので、当該部分をそのように書き直した。（変更箇所：要素解説−article要素）
- article要素のid属性について、附則では再度第一条からカウントアップされることとなるので、本則とは異なるid属性値を配布可能なように設定ルールを追加した。（変更箇所：要素解説−article要素）
- 空要素を許容することを明示するため、minLengthを設定。（変更箇所：スキーマ−heading要素）
- id属性のデータ型の記載において接頭辞"xsd:"を付け忘れていたのでそれを加えるとともに、id属性は複数要素において用いられるので、各要素においては単に参照させることとした。（変更箇所：スキーマ−article要素）
編集後記
先週から始まった本企画であるが、オープンな形で作業を進めていくに当たり、スキーマ作成作業等をどのような考えで行っているかであるとか、読者からどのような情報提供をいただいたかであるとか、こうした点で悩んでいるので情報提供願いたいであるとか、そういったことも明らかにしていく方がよいかと思い、このコーナーを立ち上げることとした。 読者にとって多少なりともお役立ちとなれば幸いである。
ちなみに、現段階でのwebmasterの構想では、次のようなステップで本企画を進めていく予定である。 ご参考まで。
- まずは要素解説及びスキーマを一通りまとめる。 同時に、「特定電子メールの送信の適正化等に関する法律（平成十四年法律第二十六号）」を用いて実際にマークアップしてみる（この法律を選んだ理由としては、第一に法改正が一度しかされておらず、制定時からの改正をフォローできること、第二に全20条と適度な規模であること、第三にテーマ的として法学になじみのない人であっても興味・関心・知識があることが期待できることが挙げられる）。
- 実際にいくつか法令をマークアップし、その過程で気づいた足らざる点や使いづらい点などについて修正するとともに、作成に当たって参考としたサイトなどの関連リソースをまとめる。 （この辺りでyahooの法情報学ディレクトリへの"http://bewaad.com/hourei2XMLdocument/index.html"の登録を試してみたい。）
- 実際に立法作業を行うに不可欠であるXSLTや改正条文作成用エディタ等については、それ自体を作成することはwebmasterの手に余ると考えられるので、必要と考えられる仕様などについての考え方を文章化する。
- ニーズなどを見つつ、faqなどの周辺情報も徐々に整えていく。
大変うれしいことに、「法令 XML」でぐぐると本企画がトップに挙げられるようになった（2004-08-01現在）。 非常に幸先のよいスタートを切ったようであり、以後の作業の励みとしていきたい。
（2004-08-01記）
第2号(2004-08-08)
読者からのメール
例規集のデータベース仕様作成に携わっている方からメールをいただいた。 次の「読者からのリンク」で紹介した、履歴管理についてご意見などいただければ幸いである。
読者からのリンク
- 8月5日@gwaihirのプログラミング日記
- 先週ご紹介した圏外からのひとことさん経由。
貴重なご提言をいただいたので、以下にご紹介しつつ、それについてのwebmasterの考え方をお示ししたい。
- タグは日本語でいいのではないか、とのご指摘について。 いろいろなところの用例を見ていて、日本語データを扱う場合でも英単語のタグとしているものが多かったので、業界の常識としてはそんなものなのかと思い英単語にしていたのだが、専門家から日本語でよいとご教示いただけたので、早速改めることとしたい（ご指摘をいただく以前に今週のテキストを書き上げていたので、来週以降は日本語でタグを表記することとし、今週分以前についても随時置き換えていきたい）。 関連で一つご意見をうかがいたいのだが、属性名もまた日本語にしたほうがよいのだろうか?
- id属性に情報を詰め込みすぎ、とのご指摘について。 ご指摘のような形式だと、おそらく条等を特定する際にはXPointerの記法に従うこととなると考えられるが、その場合、法改正の前後で条が移動したときには特定の仕方が変更されることとなる。 例えば、第12条第3項が第6項に移動し、さらに第12条自体が第45条に移動した場合、その項は原案では移動に関わらず"c3.12"というid番号で直接参照されることとなるが、gwaihir氏案では移動前は"#a12.child(3,項,番号,3)"、移動後は"#a45.child(6,項,番号,6)"という形で参照されることとなる（webmaster注:各項は上記の指摘を踏まえ既に「項」要素、項番号ば「番号」属性として表記しているが、各条についてはとりあえず原案どおりのid属性指定を行なっている。 なお、この改正で元の第45条を削除するか他に移動することなくして旧第12条第3項を新第45条第6項に移動することは出来ないので、特定の可否で言えばどちらの案でも違いはない）。 gwaihir氏案の特徴は、条番号等で一意に特定できるのは各条と各編または各章（編がなく章から始まるものがあり得る）のみとなり、各項・号と各節以下（編がある場合には各章も）はいわゆるID型データの属性を持たないこととなる（「第1項」は各条にあるし、「第1節」は各章にあるので）という点。 多分もっとスキーマ作成に知見の深い人々であれば問題ないのだろうが、webmaster程度のスキルしかない人間にはこれは実は大きな問題で、氏の案では他の条等において参照する場合のデータ型としてIDREFやIDREFSが使えなくなるので、独自に同等のデータ型を定義しなければならなくなるのだが、正直これが手に余る。
- 変更履歴は別管理すべき、とのご指摘について。 確かに変更履歴までXML文書内で管理できる仕様の作成は難しい点が多く苦労しているのだが（例えば今回のincluded要素やexcluded要素は十回以上構成を試行錯誤せざるを得なかった）、素人考えでそちらの方が何かと便利かと思いそうしていた。 作るにもあとから調べるにも別管理が便利とのことだが、作るのはオーサリングツールに任せられると仮定しても、調べる場合にどのように便利か、具体的にご教示いただけるとありがたい。 なお、webmasterの整理では、改正があった際にその改正後のXML文書について、原案では当該XML文書のデータのみで改正前の状態を復元できるが、gwaihir氏案ではそれは改正前のXML文書そのものに当たる必要がある、というものであるということになる。
修正・訂正・変更レポート
- IDデータ型ではスラッシュが使えないので、ピリオドに変更した。（変更箇所:要素解説−chapter要素、section要素、subsection要素、doublesubsection要素、article要素及びclause要素）
- clause要素の内容にenforce及びtable要素を追加した。（変更箇所:要素解説及びスキーマ−clause要素）
- 文字列としてstringデータ型を用いていたが、tokenデータ型がより適切であるため、それに変更した。（変更箇所:スキーマ−name要素及びheading要素並びにclause要素のheading属性）
- chapter要素〜doublesubsecion要素における<xsd:choice>要素の記述に誤りがあったため、それを訂正した。（変更箇所:スキーマ−chapter要素、section要素、subsection要素及びdoublesubsection要素属性）
- inherit属性及びproviso属性のデータ型の記載において接頭辞"xsd:"を付け忘れていたのでそれを加えた。（変更箇所：スキーマ−heading要素及びsection要素）
編集後記
本企画についてのメールをいただいているが、できれば今後は、このコーナーで名前（もちろんハンドルネームでも可）を公開していいかどうか、一言添えていただけるとありがたい。 今後とも、公開してよいと明示的に許可を頂いていないメールについては、原則差出人の名称は伏せさせていただく取扱いとしていきたい。
「読者からのリンク」でお示しした論点については、是非皆様のご意見をお伺いしたいので、メールをお送りいただいたり、ご自身のサイトで触れていただければ幸いだ。
（2004-08-08記）
[法令XML文書化計画]:舞台裏通信第3号(2004-08-16)
読者からのメール
本企画でまとめているサブセットの名称について、「ナイス法令」というご提案をいただいた。 あらかじめお断りしておかなかったwebmasterの手落ちであるが、通常この手のサブセットの名称は略語系が多く、ご提案の名称はむしろアプリになじむのではないかと考える。
読者からのリンク
- 8月5日@gwaihirのプログラミング日記（続）
- 先週ご紹介したgwaihir氏のご提案であるが、履歴管理については、ご提案どおり別管理することとしたい。 理由は単純で−気づいてみれば見落としていたのが恥ずかしい限りだが−、現存する法令のテキストデータは、当然ながら履歴情報を含んでいないからである。 本企画でとりまとめたスキーマの活用に当たっては、なによりまず法令をXML文書化することからはじめていただく必要があり、そのハードルはできるだけ低くして当然である。 したがって、履歴情報は別管理として、生のテキストをそのままXML文書化の原データとして使えるようにしたい。
修正・訂正・変更レポート
- 「別表」を表す要素を「別表要素」に、「項」を表す要素名を「項要素」に変更した。（変更箇所:要素解説及びスキーマ−attachedTable要素、clause要素及び関連要素）
- 本則が項のみからなる場合があるので、main要素の内容に項要素を追加した。（変更箇所:要素解説及びスキーマ−main要素）
- 履歴管理方法の変更に伴い、関連する属性を訂正した。（変更箇所:要素解説及びスキーマ−別表要素、explanation要素、part要素からdoublesubsection要素まで、article要素、項要素）
編集後記
既述のとおり履歴管理を別途行うこととしたが、history要素などの関係する要素の取扱いについては、当面ペンディングとさせていただきたい。
要素名の日本語化に伴い多くの修正を行うこととなるが、それらについては作業の便宜上、"writings"ページ及び時系列アーカイヴに反映させず、要素解説ページのみに反映させていただくこととするので、お含み置きいただきたい。
（2004-08-16記）
第4号(2004-08-22)
修正・訂正・変更レポート
- 「編」を表す要素を「編要素」に、「章」を表す要素を「章要素」に、「節」を表す要素を「節要素」に、「款」を表す要素を「款要素」に、「目」を表す要素名を「目要素」に変更した。（変更箇所:要素解説及びスキーマ−part要素からdoublesubsection要素まで及び関連要素）
編集後記
今回から、インライン要素グループと呼んでいる諸要素の定義に入った。 HTMLに倣えば、これまでもインライン要素と呼ぶべき要素をいくつか定義してきたが（区要素など）、当サブセットにおいては、文字列と混在して用いることのできる要素をインライン要素と呼ぶこととしたので、ご了解いただきたい。
法案作成のチョンボ防止のみを目的とするのであれば、今回定義した諸要素でインライン要素は最低限の要求にかなうと考えるが、他にもこういった要素があった方がいい、といったアイデアがあれば、ぜひともお寄せいただきたい。 また、法令のデータベース管理など、他の目的を考えるとこういった要素があった方がいい、というアイデアも同様にご教示いただけるとありがたい（法令中の字句の定義に関する要素はあった方がいいのかな、と考え中）。
（2004-08-22記）
第5号(2004-08-31)
読者からのリンク
- 8月28日@ダメオタ官僚日記
- 内閣法制局の法令審査支援システムに係る1億円予算要求（後で詳述）に関連して。
- 8月28日@続・航海日誌
- ダメオタ官僚日記さんと同じく、内閣法制局の1億円予算要求に関連して。
修正・訂正・変更レポート
- 章等の「名前」を表す要素を「名前要素」に、「条」を表す要素を「条要素」に、「見出し」を表す要素を「見出し要素」に、各号列記以外の部分（柱書き）を表す要素を「文章要素」に、各文を表す要素名を「文要素」に変更した。（変更箇所:要素解説及びスキーマ−name要素、article要素、heading要素、line要素、sentence要素及び関連要素）
- 附則が項のみからなる場合において、その項に見出しが付される場合に属性で処理することとしていたが、見出し要素で処理することとした。（変更箇所:要素解説及びスキーマ−項要素）
編集後記
「読者からのリンク」で触れた内閣法制局の法令審査支援システムだが、その情報は朝日新聞の報道と毎日新聞の報道しかなく、仕様に類するものはそのうち朝日のそれに頼るしかないのでひょっとしたら誹謗中傷になってしまうかもしれないのだが、報道が正しいとすれば、この法令審査支援システムとやら、どうやったらこんなタコな仕様を考えつくのか想像がつかないほどのシロモノだ。どんな仕様かはリンク先をご覧いただくとして（リンクが切れている場合は、上記のダメオタ官僚日記さんをご覧いただきたい）、何がどうタコなのか。
なんで「作成」支援システムではなく「審査」支援システムにしようと考えたのだろうか。
改正法案をパソコンに入力
（条文ミス防止、ソフト頼み 内閣法制局が１億円予算要求@アサヒ・コム）というからには、作るまでは結局今までと何ら変わらないということになる。
ミスを減らしたかったら、ミスを見つけやすくするのも大事だろうが、それ以前にミスが少なくなるようすべきだろう。
ついでに言えば、法案作成は一太郎でやるところが多いが、WordやOASYSで作っているところもある。
「入力」とはそれぞれのアプリのファイル保存形式に従ったバイナリデータを食わせることを言うのだろうが、その処理エンジンだけで余計なコストが追加されるよな。
このことから、必然的に生のテキストを用いることとならざるを得なくなる（バイナリデータを使うから正しい意味で生のテキストではないのだが、このシステムで活用するのはテキストデータだけであろう）。
つまりはマークアップされたもののように、データ自身には構造や意味についての情報が埋め込まれておらず、文章を解析してから処理を行うこととなる。
多分1億円もかかる最大の理由はこの解析エンジンの開発だと思うが、いくら法律が定型的な文章だと言っても自然言語であることに変わりはない。
だから、今回起きた、新しい条項の挿入による前後関係のずれ、引用の誤りなどがないかどうかの点検の必要性を指摘する
（同上）ことしかできないのだ。
本企画は未完成だから偉そうなことは言えないが、タスマニア（オーストラリア）のEnActやアメリカのLegislative Documents in XML at the United States House of Representativesを直訳して導入した方がよほどコストパフォーマンスがいいと思われる。 その方が少なくとも、作っては見たものの使い物にならないようなシステムになってしまうリスクは回避できるだろう。
（2004-08-31記）
第6号(2004-09-05)
修正・訂正・変更レポート
- ルート要素を「法令要素」に、「法令名」を表す要素を「法令名要素」に、「前文（制定文）」を表す要素を「前文要素」に、「本則」を表す要素を「本則要素」に、「附則」を表す要素名を「附則要素」に変更した。（変更箇所:要素解説及びスキーマ−code要素、title要素、preamble要素、main要素、appendix要素及び関連要素）
編集後記
前回、法制局の法令審査支援システムについて、タスマニア（オーストラリア）のEnActやアメリカのLegislative Documents in XML at the United States House of Representativesを直訳して導入すればということを書いたのだが、訳するまでもなく日本においてすでに同様のシステムが開発されているのを発見した。 株式会社クレステックが開発したじょうれいくん®である。 もうオープン開発であることしか本企画の存在意義がなくなってしまっているのだが（笑）、法制局もこれをカスタマイズして法令作成支援システムを作ればいいんじゃないかと思う。 多分、1億円はかからないんじゃないの?
ところで、本企画が2ちゃんのどこかのスレに紹介されていたらしいのだが、ご存知の方はいらっしゃるだろうか。 ご教示いただければ幸いである。
（2004-09-05記）
第7号(2004-09-21)
修正・訂正・変更レポート
- 「目次」を表す要素を「目次要素」に変更した。（変更箇所:要素解説及びスキーマ−tableOfContents要素及び関連要素）
編集後記
前回、本企画が2ちゃんのどこかのスレに紹介されていたらしいということを書いたが、ニュース速報＋板の「【行政】条項ずれや引用の誤り等"条文ミス"防止、ソフト頼み 内閣法制局が１億円要求」スレ（webmaster注:既に過去ログ倉庫に入っている）であった。 何度か書き込んでageに努めていたが、さすがはニュー速＋、あっという間に消えていってしまったのだった（笑）。
（2004-09-21記）
第8号(2004-10-31)
読者からのメール
実際にXMLの仕様制定経験のある方から、以下のようなメールをいただいた（引用中、「○○○のXMLにも関係」は、実際は固有名）。
法令XML文書化計画を興味深く拝見しました． XMLの仕様制定にさんざん携わってきた私ですが、最近は○○○のXMLにも関係しています。
法律の例，改正の例を公開していただけると、議論が深まると思います． また、改正をXMLで書くことによって，何を自動化したいかについても具体例がほしいところです。 スキーマには，当面手をださないほうが良いと思います． （スキーマはDTDかRELAX NGにしましょう。 W3C XML SchemaはWebサービスかデータベース用で、人間が読む文書には向きませんよ。）
改正をXMLで書いて，改正後の法律を自動生成するというのも一つの方法ですが，別の方法もあります． 改正後の法律を書いてしまって，改正前の法律と比較し，そこから改正内容を逆算するという方法です． なお、XMLの差分を求めるシステムとしてDeltaXMLという商品があります。
それぞれのご指摘については、以下のように考えている。
- 改正の例示について
- 近々試案を公開予定。
- スキーマについて
- 素人が、どうせなら最新のものでと思ってXML Schemaに手を出したのが間違いだったということで（笑）。 つまり、DTDやRELAX NGで書けるのにあえてXML Schemaで書いたのではなく、この企画にあわせてXML Schemaを覚えたのが実態である。 ご助言に従い、当面スキーマの記載はやめることとしたい。
- 改正方法について
- 改正をXMLで書くことを基本に考えている。 というのも、単なるテキストデータとしてまず改正案を作成することとすると、作成段階でのツール活用が限られると思われるからである。 XMLにより改正段階からマークアップできれば、それに応じた開発環境による支援が可能ではないかと素人的には思うのだが、この点、誤りがあればご教示いただきたい。
編集後記
法律時報９月号・10月号において、タスマニアのEnActについての紹介がなされたが、XMLと法改正作業の相性の良さがよくまとまった記事だと思う。 もう少しシステムの内容が紹介されていると、webmasterとしては作業の参考になるように思われうれしかったのだが・・・。
（2004-10-31記）