Last modified : 2014. 10. 13

Philosophy

KARAS の設計方針とは別の、抽象的な考えについて解説しています。

設計方針や設計根拠は示されるべき

例えそれがどんなに小さなプロダクトであったとしても、オープンソースプロダクトのコンセプトと設計根拠は示されるべきです。 理由はいくつかあります。

1つは同じようなプロダクトの増殖を防ぐためです。これは"ライセンスの氾濫(License Proliferation)"と同じです。 増殖を防ぐためには、多くのユーザに思想と設計根拠を明示して、それに賛同してもらう必要があります。 また理由を示すことで、設計についてより具体的な議論をすることができます。

もう1つの理由は、将来的に、より良いプロダクトを発生させるためです。プロダクトの良い点は新たなプロダクトに採用することができます。 将来的にコンピュータが扱うことができることは増えるので、今あるプロダクトがそのすべてを扱うことができなくなるのは明らかです。 新たなプロダクトを作るために、過去にあるプロダクトの開発の経緯を知ることは重要です。 そして、同じ失敗を繰り返すことは良くありません。

示されるべき設計根拠

WHATWG が Is design rationale documented? で述べているように、すべての議論や検討、設計根拠を明記することはとても大変で、またそのようなドキュメントは多くのページから構成されることになります。 このことは確かに正しいです。ただし、少なくても、その設計に決定するための重要な理由については示すべきです。

Markdown や reStructuredText は素晴らしいが十分でない

Markdown や reStructuredText は素晴らしい発明です。 特に Markdown は日常的な習慣の中で使われる通俗的な記法を用いているので、インターフェースとしてとても優れていると思います。 しかし私にとって Markdown では機能が足りず、reStructuredText は複雑すぎました。 他にも textlie などの有名な軽量マークアップ言語は確認しましたが、いずれも私を納得させることはできませんでした。 唯一 SkrivML だけが私と似た思想、理念で設計されていることが分かりましたが、それでも、私は満足しませんでした。 私は私のアイデアが素晴らしいものだと信じて 、KARAS を開発しました。

多くの場合は Markdown で十分でしょう。私もそう思うことがあります。そして Markdown の最も素晴らしい点は、その名前だと私は思います。

LML and PDL

LML と PDL(Page Description Language) のリストです。いくつかのページは日本語のページです。 また、Wikipedia のページ - Lightweight markup language に関連する情報がよくまとめられています。

LML 以外の参考

KARAS の構文を設計するために LML を参考にするのは当然です。 KARAS はプログラミング言語や正規表現も参考にしています。

また、KARAS を使ってどのようなテキストやドキュメントを書けるかを検討しました。 学術論文、新聞、お菓子や薬のパッケージ、ダイレクトメール、小説、辞書などを観察しました。 HTML と CSS を使ってレイアウトすることが難しいパターンを除いて、 KARAS は多くの種類のドキュメントを書くことができます。

もしかすると KARAS の機能は十分ではありません。しかし、より多くの機能があれば、より複雑になってしまいます。 そのような広い範囲に対応するシステムが必要なときは、私たちは HTML を使うべきです。 また、必要なら、 KARAS はプラグイン構文によってその機能を拡張することができます。

セマンティックWebのような設計思想は遠い将来に排除されるべきである

セマンティックWebの概念はしばらくの間は残るでしょう。 しかしながら、あるテキストがどのような情報や性質を示しているのかを、 自動で識別して分類することが、この分野の究極的な目標であると私は考えています。 そしてそれが将来実現することを期待しています。

そのようなシステムのユーザは、LMLがするように、テキストの意味を入力する必要はなくなり、 今よりも更に自然にドキュメントを書くことができるでしょう。 KARAS はそのような未来がくるまで使うことができれば良いと考えています。

とは言え、人間がドキュメントを目で見て認識することに変わりはありません。 したがって文章やそのブロックを分かり易く記述する手法はしばらくの間はなくなることはないでしょう。 また HTML のような、意味のあるテキストを提供するためのフォーマットも、 ドキュメントを解析した結果を保存するために、しばらくの間はなくなることがないでしょう。

HTML5 は価値を損ねている

HTML5 の記事を多く見かけるようになりました(in 2014)。 しかしながら、実際のところ、その内容は Canvas 要素に Javascript や CSS3 を組み合わせたものがほとんどです。 新たに定義された要素は蔑ろにされています。しかし気持ちはよく分かるのです。 テキストの意味を考えながら、タグを打つのは凄く面倒です。 KARAS タグを打つ面倒を取り払って HTML の価値を高めてくれるでしょう。

出力形式を HTML に限定する必要はない

KARAS は標準的な出力フォーマットを HTML としていますが、これに限らず、あらゆる環境で KARAS の構文を採用しても良です。 EPUB や PDF が必要な場合には、HTML を中間フォーマットとして、既存のツールを使って変換するのは1つの手です。 もちろん専用のコンバータを開発しても良いです。 必要なら、EPUB や PDF に必要なパラメータは、KARAS の拡張記法によって記述することができます。

HTML に対する私の見解

私の HTML に対する見解をここで述べておきます。 これらは KARAS を設計していたときに考えられたものです。 私の基本姿勢は、より簡潔に、より分かりやすく、直せるものは直すべきだ、です。 これは W3C などの姿勢とは異なります。

次のことに注意してください。 私は W3C や WHATWG が行ってきた、議論の記録の一部しか読んでいません。 すべての経緯と貢献者の考えを知っているわけではありません。 そして、私は貢献者の方々には尊敬と感謝の念を持っています。

small 要素は名前を変更するべき

2014年1月現在、HTML5 では、 small 要素は、免責事項や注意事項を述べるために使うこと、と推奨されています。 この設計は私は間違いであると思います。 私たちは small という単語から、この規定について推測できないためです。

小さな文字を書く目的で、 私たちは small という単語を時折使います。 ふつう、特定の文字だけを小さくしようとすると <span class= "small"> を利用するでしょう。 このことを考えたとき、 small 要素の設計は明らかに誤りであると感じました。 例えそれが歴史の中で当たり前のように使われていてもです。

cite 要素は出典を示すために使われるべき

2014年1月現在、HTML5 では、 cite 要素は、書籍や論文などの作品のタイトルを述べるために使うわれるべき、と定義されています。 この設計は私は間違いであると思います。 cite という単語の本来の意味は、引用する、だからです。 私たちが何かを引用するときは、それが作品であっても人の発言であっても良いはずです。 しかし、長く続いた(悪しき)習慣に基づき、 cite 要素は作品タイトルを示すために使うことができても、発言者を示すために使うことはできなくなりました。 これは非常に残念です。 習慣やデファクトスタンダードに基づいてルールを決めることは悪いことではありません。 しかしながら、私たちは間違いを正すことができるということを忘れてはいけません。

私は KARAS のユーザが cite 要素を、発言者を示すために使うことを希望しています。 KARAS では @@ で閉じたテキストは cite 要素として出力されます。 また @ をもう1つ増やすことで small 要素として出力されます。

もしもあなたが私に同調してくれるのなら、発言者を示すために @ を2つ書いて cite 要素を出力してください。 W3C や WHATWG の見解に従うべきだと思うのであれば、@ を3つ書いて small 要素を出力することができます。 あるいは strong(b) 要素や span 要素を使うべきでしょう。 KARAS には span 要素を出力するためのインライングループという構文も用意されています。

2014年1月現在、Twitter のタイムライン上の発言者は strong 要素でマークアップされています。 Twitter-Bootstrap の Blockquote の項目では、 small 要素になっていますが。