waf_thread

write-and-forget

markdown で妥協して新しくブログを作ることにした。

HTML では足りない！

メタデータや意味を十全に与えたいと考えたとき、 markdown は言うに及ばず、ある種の拡張なしの HTML であっても表現力に不満がある。

blockquote が貧弱すぎる

たとえば HTML で何らかのまとまった引用をしたいとき用いる blockquote タグを考えてみよう。 blockquote に特有の意味を与えられる機構は cite 属性と cite タグのみである。

HTML LS の cite 属性の解説 ():

Content inside a blockquote must be quoted from another source, whose address, if it has one, may be cited in the cite attribute.

HTML LS の cite タグの解説 ():

The cite element represents the title of a work (e.g. a book, a paper, an essay, a poem, a score, a song, a script, a film, a TV show, a game, a sculpture, a painting, a theatre production, a play, an opera, a musical, an exhibition, a legal case report, a computer program, etc.). This can be a work that is being quoted or referenced in detail (i.e., a citation), or it can just be a work that is mentioned in passing.

それ以外の情報は、著者や発言者も、参照日時も、出版日や版も、「強調は引用者による」も、区別して表現するためのタグや属性はない。

MDN に載っている例では以下のようになっている:

<figure>
  <blockquote>
    <p>It was a bright cold day in April, and the clocks were striking thirteen.</p>
  </blockquote>
  <figcaption>
    First sentence in <cite><a href="http://www.george-orwell.org/1984/0.html">Nineteen Eighty-Four</a></cite> by George
    Orwell (Part 1, Chapter 1).
  </figcaption>
</figure>

そう珍しいものではない形式の引用だが汎用のマークアップ (figure と figcaption 要素) で記述せねば紐付けられず、また "George Orwell" が著者である (しかし発言者ではない) ことは figure 要素でマークアップしてなお機械可読に表現されていないことがわかる。 もちろん「(中略)」を本文と区別して表現する能力もない。

もちろん「(中略)」を本文と区別して表現する能力もない。

万が一このような引用をする羽目になったら、「(中略)」が本当に何かを略しているのか、それとも単に記号列として「(」「中」「略」「)」が元からあったものなのか、引用の外側から補足が必要になる。 もっとも、機械可読に表現可能だったとしても補足するに越したことはないであろうが。

似たような問題で、訳註が存在する文書をさらに翻訳して訳註を加えた場合にどれが翻訳前文書内の訳註でどれが最終翻訳者による訳註なのかマークアップで区別する標準的な方法がないというのも、 HTML の引用まわりの表現力の弱さの一例である。

さらには markdown では figure 要素どころか cite 属性でさえ生の HTML の挿入なしに記述できない。 技術文書ばかりでなく日常的な文書であっても markdown や素朴な HTML では圧倒的に表現力が不足しており、 HTML タグに microdata なり RDFa Lite なりの追加仕様を組み合わせてはじめてまともなレベルになるわけで、喩えるなら高級言語を許されずアセンブリ言語を使わされているばかりか CFI directive まで常用せねばならないようなものである。 (一応 microdata は WHATWG HTML 標準内で定義されているようだが……。) このような迂遠なものを頻繁に作成し長期間メンテナンスするような文書群で使いたくはなかった。

参照能力と参照外し能力の欠如

HTML で markdown よりマシになるならタグが足りずともひとまず HTML で書けば良いではないかという話になるわけで、部分的には実際その通りなのだが、話はそれで終わらない。 上に挙げた例は microdata のような追加のメタデータで意味を与えれば解決できる問題だったが、根本的に重複なしでの記述が難しい課題がある。 それはクロスリファレンスや目次 (ToC) だ。

たとえば同じページ内の特定のセクションへリンクしたいとき、そのリンクのテキストをセクション名から持ってきたり、あるいはセクション番号を利用したいということはあるだろう。 ToC (目次, Table of Contents) はその最たる例である。 HTML ではこれが自動化できず、自分でテキストを複製してきたりカウントして数字を直接使わねばならない。 一応 CSS でカウンタを使うことはできるが、その数字はあくまでスタイリングに使うことしかできず、マウスでドラッグして選択可能な本文として配置することはできない。 本文の一部としてそういった参照をしたくばソース中で複製・決め打ちする他なく、つまり文書を編集する際にミスして一貫性がなくなる (数字や文字列が実態と一致しなくなる) 可能性がそれなりに高い。

footnote (脚注) も同じような問題を抱えており、 footnote をまとめる footer なり aside 要素なりにおける記載と、マウスホバーしたとき表示されるツールチップ (素朴には title 属性で実装できる) で同じ文章を表示しようとすると、ソース中でのテキストの複製が必要になる。 JavaScript を使えばどうにかできるにはできるが、それはむしろ HTML ではどうにもならないと言っているようなものである。 静的な文書に後付けの動的な機構を必須としたくはない。

このような問題を抱える HTML という形式は、人間が保守する前提のしっかりしたドキュメントのソースファイルに適しているとはいえない。

他にもいろいろ不足あり

DocBook 5 の要素一覧と比較すれば、 HTML の語彙がいかに貧弱で原始的であるかわかるだろう。 HTML では用語集も Q&A も全て dl タグで表現することになるし、ファイルパスも変数名も短いコード片もすべて code タグで表現することになる。

HTML ではそのように情報を潰して潰して、それでもどうにかスタイルを変えるとよさそうなものだけを区別した結果が今定義されているタグなのであって、根本的に機械可読な意味を残すための形式ではない。 あくまで出力 (特に表示と印刷) のための形式か、あるいは編集がギリギリできるくらいの中間形式と捉えるくらいが妥当で、セマンティックな入力として最適に作られた形式と考えるべきではない。

markdown で諦める (ただし限定的に)

これだけ不満がありながら markdown を使うことにした理由は、単にこの調子でやっていくと記事にできたはずの考えまでどんどん揮発していきそうで、それはそれで非常に良くないと思ったからである。 最近 (というほど最近でもないが) XML 処理系を字句解析器レベルから自分で実装しようとしており (libxml2 と libxslt は偉大だがどうにも満足できない事情があった)、進捗は確かにあるもののこの調子ではあと何年かかるかわかったものではない。 markdown のように意味を込めるのが難しい形式であっても、そもそも意味を込める意義の薄い用途に限っては使い物になる。

旧ブログではどんなに長く技術的な情報であっても、あるいはどんなに私的でどうでもいい情報であっても、無関係に豊かな語彙を活用して同じ場所にブログ記事としてしたためていた。 しかし冷静に考えて、誤った実装方法を警告する記事と技術的思想の解説記事と私的な日記が区別されず同居しているのは明らかに体験が悪い。 体験が悪かろうと区別が難しければ同居させるしかないことを私はここ十数年の SNS アカウント運用で身をもって学んだわけだが、そうはいってもやはり明らかに性質の異なる記事というのは存在するのである。

その「性質」が最も極端なのが、日記である。 日記は後から書き直したり改善することが滅多になく (稀に追記やリンク URL 修正はあるかもしれない)、紐付けられたプライマリな日時が文脈として本質的に重要で、かつ正しさを価値判断の基準に持たない。 (一応補足すると、これは正しいことが価値を生まないという意味ではなく、誤った記述があるという事実そのものにも価値が認められることがあるということ。)

何より個人的に、他人の私信とかいうやつは、ごく一部自分に刺さるトピックのものを除いてかなりどうでもいい。 日記の価値の8割くらい (数字は適当) は、他人に読まれることではなく自分に読み返されることによってその存在意義を回収するのではないだろうかと思えるほどである。 かような日記という空虚でどうでもいい記事群は、他人が読んで役立てられる前提の “どうでもよくない” 記事と同列で扱うようなものではなく、相応に人目につきづらい日陰に埋もれさせたい。 となれば、日記を正しく weblog として分離して、日記でなく正しさが重要でメンテナンスに値するような記事を別の場所でリッチにやるというのが妥当に思われる。

そういったわけで、このたび日記や雑感の集積場所としてのブログをこうして分離して、こちらは既存実装で雑に用意することにした。 この文脈であれば、むしろ表現力が弱いという制約は「表現力が欲しくなるような用途に使うべからず」という誓約としてポジティブに機能させられよう。 そして本文形式を高度に拡張可能な static site generator を使わないことで、「埋もれるべき日陰の場所を必要以上に “良く” しない」という自分への枷とする。 このブログは (現時点では) Zola を使っており、これは shortcode の定義機能などがあるという点では高度だが、本文が基本的に markdown 前提であるという点では拡張性に乏しい。

旧ブログを使わない理由

実はオレオレ XML スキーマを利用して書けるブログを nanoc で用意して既に持っている。 nanoc は極めて拡張性が高く、本文が markdown である必要がないばかりか、オレオレ XML 文書を HTML にすることもできる。 そちらを使わず自力で XML 処理系を実装する理由はいくつかあるが、端的には Rust で書きたいから (あるいは Rust 以外で書きたくないから) ということになる。

nanoc はキャッシュの仕組みがあってなおまあまあ遅かったり、フレームワークから少々外れたところでがっつりコードを書くことになったり、既存のフィルタも処理を改変したいため自分でパッチをあてる羽目になったり、 XSLT 1.0 範囲での記述だと面倒で汎用言語のロジック表現力を使いたかったりなどで、現状の旧ブログではあまり素直に nanoc に乗りきれていない。 また nanoc では、 XSLT によるレイアウトは XSLT 側での import や include による依存追跡がうまくできずキャッシュが不適切に利用されてしまったり、 XSLT でのレイアウトはページあたり1回しかできないため複数段の XSLT スタイルシート適用が素直にはできないという問題もあり、 XSLT の利用は手厚いサポートを受けているとはいえない状況である。 これは XSLT 前提でオレオレ XML を書きまくっている私にとっては懸念材料で、それならいっそ最初から Rust で書いた方がコントロールも効くし便利で楽しいだろうということで自前実装を試みることになった。

そしてその自前実装が完成するまで待つほどのことでもないような記事を書き出す先として、また先述のように「どうでもいい」記事を隔離する場所として、新たにこのブログを用意した。

write-and-forget

このブログに置く記事の基準はただひとつ、「書いたきりノーメンテナンスで、あるいは最小限の追記に留めて放置することに躊躇いがないこと」である。

たとえば次のように判断する。

  • 「この日こういったことがあった、こう感じた」は当時の事実認識のスナップショットとして価値があるので良い。
    • 認識が変わってどうしても補足したくなったら、後日に紐付けて別の記事を作ってリンクだけ追加する。旧記事そのものを訂正してはいけない。
  • 「このバージョンの処理系ではこう書くのが正しい」は「後のバージョンでは別のこのような書き方が正しい」と大きめの情報を補足したくなるので望ましくない。
    • 「このバージョンの処理系にこういったバグがあった」までなら「後のバージョンでは直った」という僅かな追記で済むので良い。
  • 「こういったトラブルがあったのでこう対処した (できなかった)」は、成果がなかろうと誤っていようと作業記録としての価値があるので良い。
    • 誤ったリスクある手順があとで発見されたら「この手順は適当でないので真似してはいけない」程度の追記で済ますこと。正しい手順を長々と解説しようとするのは望ましくない。
      • 誤っている理由の追加くらいはあっても良い。
  • 製品の評価 (レビュー) などは、各種観点あるいは総合的にみての評価という特定構造のメタデータを共通して持つような記事なので望ましくない。
    • 多少なりとも機械可読な情報を提供したい気持ちがあるなら、最初からそのように設計したり後から既存データの構造を弄れるような柔軟なシステムに乗せるべき。
    • あくまで感想や経験を主観的に述べるものであって結論として点数をつけたりしないようなものであれば、まあ良いか……

このような性質を、 fire-and-forget という概念をもじって write-and-forget と呼ぶことにした。 fire-and-forget とはミサイル兵器だけでなくしばしばプログラミングの文脈でも用いられる概念で、ミサイルやリクエストやタスクをひとたび fire (発射) すればその後の動作を監視したりコントロールする必要がないという性質のことである。

そしてこのブログを write-and-forget メディアにするという戒めとして、 waf_thread と命名することにした。 今後このサイトには忘れられるべき記事が打ち捨てられていくことになるだろう。