「no title」にまつわる有益な話…を、…しません。ほんとに目に留まって欲しくないので無題にしてる。
ちょっと今「本題作業」でどツボっちゃっててなぁ、なのでちょっと「息抜き」がてら、前から書きたかったネタでブロぐっとこうかと。
「はてぶ」なプラグインを入れちゃったばっかりに、最近は「はてぶ数」で流行ってんのかそうでないのかがおよそわかるようになってしまった。すなわち「十分に知られてるんだろうなぁ」てことをこれから書く。ゆえ、「読む価値ないと思うよ、たいがいの人には」。
なんでもそうなんだろうけれど、「わかっている人には自明過ぎて、わかっていない人にとっては問題意識を持つ機会に恵まれること自体が皆無」というほどエンジニア間での乖離が激しいものってのはあるものである。今回の話はまさしくその代表格であるところの「データ交換形式」の話。
作業に忙殺されて勉強出来ないからなのか、たとえ XML + XML Schema が不条理で不合理で牛刀で、どれだけ苦痛を強いられても、一切疑問を感じずにこれに従い続ける開発者が多いのはそう… java と Microsoft のせいだ。java と Microsoft だけがバッチリ XML 環境を真っ先に「パーフェクト」(に近い)ものにしてしまったために、末端エンジニアが疑問を感じにくくなってしまった。せいぜい「第二世代」にアプリケーションを刷新しなければならない際に、「前回の性能の悪さの反省を踏まえて」、XML Schema によるアプローチに疑問が投げかけられる「チャンス」が、あるかないか、という程度である。
ワタシはこのサイトでよく XML 批判めいたことを言うんだけれど、無論「XML よ、永遠に消えちまえ」なんてことを考えてるわけじゃないし、そうは言ってない。XML も(もとをただせばその元になった SGML も)、「正形式な文書の記述」のためには非常に優れたインフラである。すなわち、「様式」に従った、「ドキュメント」を書くのには非常に良く出来ていて、「SGML の間違った使い方をしてしまった HTML の 3.x まで」だけの世界に戻ろうものなら、現代から EC なんか消えてなくなってしまうであろう。そう、あなたの大好きな amazon は成立しない。
問題はそう、「データ交換形式」として XML (と DTD や XML Schema) を採用することの是非、の話である。これはあなたが考える以上に複雑でコストがかかる。実行時の時間的コスト、開発時の人的コスト、そして「金銭的コスト」、全てにおいてである。そしてこのコストを当然のものとして受け止めてしまうエンジニアが多過ぎることが問題。
「データ交換形式」というものが必要になるのはなぜか? そこからわからない人は「多くはないと信じたい」けれど、現実にはそうもいかない。「問題意識を持つ機会に恵まれること自体が皆無」に該当するエンジニアにとっては「データ交換形式」なんて言葉自体が未知なことがほとんどで、あげくに「勝手に言葉を発明するな」と怒り出すバカもいる。ウソだと思うでしょう? いや、こんなん日常に溢れてるよ。どうやら「自分が知らないことは世界ではない」らしい、このタイプのエンジニアにとっては。
「データ交換形式」は、究極的には「層をまたぐ際には必ず必要」である。プログラムの関数間のような、相当無頓着でいい層もあれば、機器をまたぐような、「データ交換」にとっては難儀な層もあるが、とにかく「異質な層と行き来する境界」においては必ず必要となるものである。
SGML の歴史は驚くほど古いが、HTML によって脚光を浴び、「正しい SGML よ、再び!」と XML が登場する以前の世界においては、「データ交換形式」は「独自バイナリフォーマット」か「独自テキストフォーマット」の二択であった。現代においては、「もとはといえば独自だが良く考えられた標準バイナリフォーマット」と「XML などのデータ交換にも利用できる、バリデーションのインフラが完備した標準テキストフォーマット」が加わったことで、少しは、というかだいぶハッピーにはなっている。したがって現代においては、こういう順序で考えることになる:
- システム内部共通、程度のデータ交換であれば、独自バイナリ、最もシンプルには C 構造体、でも相変わらず良い、かもしれない。
- システム内部共通、程度のデータ交換であっても、出来合いのバイナリフォーマットがコストを下げるかもしれない。
- システム内部共通、程度のデータ交換であっても、テキストフォーマットの採用が説得力を持つこともあるかもしれない。
- システムをまたいだ連携においては、インターフェイスが枯れないとコストが嵩む形式は採用しがたい。
- システムをまたいだ連携においては、すなわち、単純な構造体での連携は採用しない方が身のため。
- システムをまたいだ連携においては、従って、せめてフィールドの増減くらいにはへこたれないフォーマットを採用したい。
- システムをまたいだ連携においては、従って、そうしたことが可能なバイナリフォーマットか、なんらかの標準テキストフォーマットを採用したい。
2、6、7 まで思考が至れば初めて messagepack や protocolbuffer や、あるいは IDL の「意味」がわかる。これらはまさしく「ただの構造体では困る」のためにある。公式の説明がどうしても「json や xml に較べてどうだ!」というチャームポイントを宣伝しがちなので忘れられがちだが、元はと言えばそういうことである。そして、「テキストを採用するならば」、自力でパーサを書かずに済むもの、ということがほぼだいたいにおいては「不可欠」なニーズであり、その中から自分達のプロジェクトにとって最も相応しいものを採用する流れとなるが、採用のための観点は様々であり、適宜考える必要がある。
しかしながら「XML の全てに疑問を抱かない」エンジニアがこの思考を辿ることを期待することは絶望的である。見かけ上は XML + XML Schema は「パーフェクト」だからだ、ということもあるだろう。必要なのは「形式の強要」「型の強制」であり、これによりまさしく「design by contract」を実現出来る。素晴らしい。
繰り返すが、XML は「文書の形式の強要・文書の要素の型の強制」を「可能にした」、「文書のための」インフラである。「データ交換に適した」ものというゴールは最初からない。「そうすることも可能だ」というだけの話なのであって、決して最適ではない。このことが最も顕わとなるのがまさしく「mixed content」と「スキーマレスな素の XML」だ。前者は「文書のため」ならではのものであって、後者は「あらゆるものがテキスト」という地獄に落ちる。後者がそれでも採用されるのは無論、「スキーマの開発こそが大仕事」だからでもあり、また、実行時のオーバヘッドを避けたければ、スキーマは軽視されがちだ。
XML 黎明期なんかはワタシだって歓喜し、世界が良くなることを期待したのである。けれども世界は学習したのだ、それらのことを。「もっとデータ交換だけに最適なものを作らねば」。
json は元はと言えば「javascript のデータ記述仕様だけを抽出したもの」なので、動機が「汎用データ交換」を狙ったものなのかはワタシにはわからない。けれども「そのように」使うことが出来る。yaml はまさしく json に触発されたものだと思う。ちょうど json のスーパーセットになるように設計されている。今のところこの2つの二大巨頭が支配的なのかなと思うし、他のものを改まって再発明しようとする動きは、少なくともあっても目立たない。
json と yaml の良さは、「スキーマ」などという大仰な「追加仕様」を持ち込むまでもなく「型」が組み込みな点である。コンテナとしては「シーケンス」(リスト)、「オブジェクト」(ぶっちゃければ「辞書」)、ネイティブ型としての「文字列」「数値」「ブーリアン」だ。XML Schema のない XML ではこれらは全て読み手にとっては「シーケンスだと信じたい」「辞書であって欲しい」「数値しか入ってないと嬉しい」「ブーリアンだとありがたい」となる。これだけでもつまり json、yaml は素晴らしいのである。
さて問題はここから。
「独自バイナリフォーマット」にはあり、「素の json、素の yaml にないもの」、それは何か? これは「構造の強制」だ。例えば「個人情報基本情報には氏名・住所・電話番号の三要素が必須である」という様式の強制をしたくても、これは「素の json、素の yaml」の範疇外であり、そうであるならば「アプリケーションが自力でバリデートする」しかない。
ないのか? いや、少なくとも json にはこれがある。そしてこの公式サイトには大量の「はてぶ」が付いている、ので、特定の人々にはもはや「常識」なのだろう。Python にもこれのライブラリがある。
実際 XMLSchema を記述することそのものが大仕事でコストがかかるのと同じく、json schema のそれだって、そう簡単なものではないのではないかと想像する。ワタシ自身がやったことがないからね、よくはわからない。「入れ子の繰り返し構造の定義方法」とかドキュメントをぱっと見で良くわからなかったりするし、そもそも「メタ記述」という行為そのものがなんであれ「頭を掻き毟る」類のものだからね、「開発コストを劇的に下げる」かと言えば、「下がる部分と代わりに上がる部分とがある」ことは明白なので、自分のプロジェクトではどうかを良く見極めてから採用した方がいいだろう。
ワタシの作業の多くは「人が撒き散らしたデータ交換形式を処理する」ことである都合、「自プロジェクトで必要なデータ交換形式」を発明しなければならない機会は少なくて、なので json schema なんかのお世話になることもなかったんだけど、必要になるか、あるいは何か余力があってやりたくなったら、ちょっと何かそのうち書くかもしれない。(→2021-06-12。)
