プログラミングは仕様決定の段階から始まっている。

　じつは去年から今年にかけて日本免疫学会と日本脊椎脊髄病学会の演題投稿システムの改修の仕事をやっていて、その（論文の）抄録を投稿する際の書式指定用の仕様の件で少々学んだことがあった。

　使えるタグとしては改行（BR）・上つき文字（SUP）・下つき文字（SUB）・イタリック（I）・ボールド（B）・アンダーライン（U）があるのだが、問題は「ユーザにしろプログラマにしろ、人間は間違える」という点にある。つまり「ユーザのミスで、開始タグと終了タグがちゃんと対応していないケースが往々にしてある」と同時に「プログラマがいきあたりばったりにプログラムを拡張したため、開始タグと終了タグがちゃんと対応していないケースうまく対応していないときの挙動が怪しい」ために、けっこう楽しいことになっていたのである。つまり、プログラムを直すと出力が崩れるのだな(^_^!)。とはいえ元の論文データは「投稿されたそのままのデータ」を使うことになっていたので、投稿者本人の要望で修正する場合を除いて触ってはいけないことになっていた。それが仮に「どう考えても入力ミス以外には考えられないあからさまな間違い」であってもである。

　……具体的にどう対処したかについては伏せておこう(^_^;)。とにかく客先の評判は上々だったらしいので、結果オーライである。

　閑話休題。実際、Ｘの二乗にアンダーラインが引かれているようなケース（上つき文字とアンダーラインの組合せ）なんていうのは珍しくないわけで、そんなのを編集していたりするとタグの対応を取るのに苦労するのは当然なのである。ところが「タグ埋め込み」みたいなことをやる場合には「分りやすいエラーメッセージを出す方法」というのがない。「見た目がおかしかったら修正」しか方法がないのである。じゃあ、どうするか。

　実装が楽な方法としては、「終了タグとして全部同じものを使う」手がある。つまり、ブロック要素である CODE や QUOTE なんかの場合、
ではなく、
と書いちゃえば、「開始タグと終了タグの対応」なんてことは考える必要がなくなる、という発想である。 Pascal 系言語はおおむねこの手を使っており、 JSP 2.0 の式言語なんかも同様である。

　とはいえこれだと HR タグなんかは $HR{} とかになって結構ウザい。てなワケで一行べったり占有するような HR タグとか H1 タグとかは
と書いてしまえ、とかいったアイディアが浮かぶ。これは C のマクロが使っている手。
　残る問題は TABLE とか DT とかいった「構造を持ったタグ」だ。こいつに関しては Wikipedia なんかでも扱いに苦慮している様子がある。入れ子になったりすることを考えると、さらに厄介だ。まあ、「下手にフォローしようと思わず、文法違反が起きたポイントから、あからさまに表示が乱れる」とかいった方法で修正しやすくするような文法を定義する、とかいった方法がとりあえず考えられると思う。

　ただ、開発の人間が直接営業をしているような零細企業以外では、「まず仕様ありき」で実装方法の検討というのは後回しになる。そうすると「言われた通りに作ろうとするとめんどくさく、しかも結果的に使いにくいものになる」のである。あげく仕様をめぐって会社と喧嘩になったりするのだ。

　「プロトタイプを開発して実装と利便性の間でトレードオフを行なうことで仕様を決める」といった手段も、ときには有効であることを頭に置いておくのは重要かもしれない。特にユーザ・インタフェースに絡む部分では。