Last modified : 2014. 10. 13

Base concept

KARAS の基本となる設計方針について解説しています。

KARAS の主たる目的はドキュメントの作成である

いくつかの LML はレイアウトや装飾のための構文を持っていますが、KARAS は持っていません。KARAS の主たる目的は、ドキュメントの生成としているためです。KARAS はドキュメントを生成するための様々なシステムに導入されるべきです。したがって、生成されたドキュメントがどのようにレイアウトされるかは、KARAS が実装されたシステムが決定するべきです。KARAS を使って出力された HTML ドキュメントは CSS によって装飾されるべきでしょう。

例外

例外として、テーブルに関する仕組みについては、レイアウトのための仕組みが含まれます。text-align (文章揃え)の設定です。これについてはいくつか理由があります。1つは既存の多くの LML が対応しているためです。もう1つは、数値を扱うセルが定義されるとき、その数字を右揃えにすることで単位を揃えて見せるためです。テーブルの見やすさはそのデザインやレイアウトに大きく左右されます。また CSS などの設定ファイルによってテーブルのデザインを微調整することは、非常に手間のかかる作業です。これらの理由から、KARAS ではテーブルでのみ、レイアウトに関する構文を定義しています。

構文のために使う記号

当たり前のことですが、ある国の言語に固有の記号を構文に使うことは良くありません。KARAS のすべての構文は、最も広く使われている文字コードである、ASCII コードに含まれている記号から構成されています。入力の容易さに差はありますが、ほとんど全ての国のキーボードで入力することができるでしょう。

次の記号が ASCII コードに含まれるすべての記号です。

| ~ \ " ` ' ! ? @ # $ % ^ & * , . ; : _ + - = < > [ ] { } ( )

構文は直感的で、可能な限り似たルールであるのが望ましい

ユーザがマークアップに集中することは良くありません。ユーザはドキュメントを書くことに集中するべきです。また、いくつものルールを覚えることは学習コストがかかります。KARAS ではこの問題を3つ方法で解決します。

  1. 記号の見た目や意味から、その構文が出力するテキストの意味を分かり易くする。
  2. いくつかの違う種類の記号を組み合わせない。
  3. 構文の構造を可能な限り似たものにする。
    • 構文は記号を2つ以上続けることで成立する。
    • 構文の記号の数を増やすことで、意味が強くなる。

これらのルールによって、KARAS は多くの機能を持ちながらも、直感的に書くことができます。

記号が連続する構文

記号を連続する構文構造は、エスケープ \ の使用頻度を下げることができます。また記号が 2 つ続けて記述されることによって、KARAS の構文とそれ以外の記述を目視によって区別しやすくなります。つまり、変換前のプレーンテキストの見通しを良くします。コピーアンドペーストしたテキストの誤変換を少なくすることもできるでしょう。

このルールは、マークアップされたテキストの変換処理を効率良く行うことにも貢献します。特定の記号が連続するかどうかで変換する処理が必要かどうかを判定することができます。

一方で、入力回数が増えるという問題があります。もしかしたら、あなたは冗長と思うかもしれません。しかしながら繰り返し入力する記号は同じ記号です。同じキーを押すだけですから、私はこのことは大きな問題にはならないと考えています。

複数の構文から同一の出力が得られるのは良くない

いくつかの LML では、複数の異なる構文が同一の結果を出力する場合があります。これは複数ユーザによって編集されるドキュメントで、混乱を起こす可能性を持っています。

このことは、プラグインや構文の変換システムを開発する際にも問題を引き起こします。1つは複数の入力方法に対応するようにシステムを開発する必要がある、という問題です。単純に、開発のコストが上がる、という問題です。

さらに、もし複数の入力に対応しないシステムが作られるようになると、もう1つの問題を引き起こします。例えば入力方法 A と B が同じ結果を出力するとします。このとき、入力方法 A に対応しない環境で、ユーザが入力方法 A を入力してしまう可能性があります。ユーザは期待した結果を得られなくなります。KARAS は、可能な限り、異なる構文が同じ出力結果を出力しないように設計されています。

空白文字を用いる構文は良くない

いくつかの LML では、例えば、整形済みテキストやネストされたリストを出力するために空白文字を使います。空白文字によって出力結果が変わることがあります。

このような構文は、空白文字を視認できない環境下でユーザの入力ミスを起こしやすく、良くありません。テキストベースの編集環境下では、可能な限り、空白文字を使う構文を定義するべきではないと考えています。また、空白文字のように見難いものの数は数えたくありません。これらの理由から、KARAS は空白文字を使う構文を持っていません。

python のようなプログラミング言語を悪いと言っているわけではありません。LML なら空白文字を扱わない方が親切だ、と私は主張しています。必ずしもエディタを必要としないからです。逆に、python もエディタがあって初めて素晴らしい力を発揮できるものと考えています。

コメントアウトは実装されるべきである

いくつかの LML は、コメントアウトの構文を持っていません。KARAS では、コメントアウトのための構文を定義しています。文章そのものにも、それがどういう意図で書かれているのか、文章設計の意図を残したいことが多々あるためです。

改行の実装は実装されるべきである

いくつかの LML は、改行の構文を持っていません。KARAS は改行の構文を持っています。その理由は次の通りです。

小説や詩などの文学作品では空の行が意味を持つことがあります。例えば改行によって、間 や静寂を表現するために用いられます。次のような文が書かれるとき、この文は1つの段落として出力されるべきです。複数の段落として出力されることは適切ではありません。

When I turned around,

THUDDDDD !!

it fell from the sky.

改行が必要になる例はこの限りではありませんが、このような状況を適切に処理するために、改行するための構文は必要です。

同じ記号の構文から出力される要素を入れ子にする必要はない

KARAS では同じ記号の構文から出力される要素を入れ子にすることはできません。そのようなルールは多くの場合に必要ではないと考えています。理由は次の通りです。

例えば、b 要素と strong 要素を入れ子にして出力するテキストはない方が良いと考えています。テキストの持つ意味が重複するからです。また装飾を目的としてそれらを入れ子にすることも良くありません。

W3C の strong 要素のサンプルでは strong 要素を入れ子にしています。strong 要素は入れ子にすることによって、重要性の順序を示すことができます。しかしながら、実際には、重要性の順序を考えながらドキュメントを書くことは少ないでしょう。もしも strong を入れ子にすることで重要性を示しても、それはプログラムに対しては役に立ちますが、人間の読者に対しては役には立ちません。重要性に順序を設ける必要があるならば、章やリストを使って、読者に伝えるべきです。軽量マークアップ言語はそのようにして使うべきです。もしもプログラムに対して役にたつドキュメントを書く必要があるのなら、HTML を使いましょう。

var 要素や code 要素にも同じです。code 要素の中にある変数のテキストに、一々 var 要素を書いていくなんて面倒です。もしもそういう出力結果が欲しければ、code 要素の内容を自動で解析するようなシステムを作るべきです。

他に、例えば、sup 要素や sub 要素を入れ子にすることも多くはないでしょう。もしも必要なら HTML タグを直接書くことで対応することができます。また、入れ子にできるような設計にしても、書かなければいけない記号の数と、HTML のために書く文字の数の差は少ないですし、そのようなプレーンテキストは読みにくいでしょう。

構文に使う記号の種類と変換速度

KARAS の構文は ASCII コードに含まれるほとんどの記号を使っています。構文の種類と使う記号の数が増えると、考慮するべきパターンが増えて、変換速度が遅くなります。事実、KARAS は他の軽量マークアップ言語よりも変換に時間がかかるでしょう。しかしながら 2014 年現在使われている PC でも十分に高速に変換されますし、PC の性能は将来的にさらに向上します。また、高速な動作を必要とするならば、変換結果をキャッシュするような仕組みをシステムが持つべきでしょう。実際に、多くの Wiki システムではキャッシュするための仕組みを導入することができます。

また、もしも多くのテキストが書かれたドキュメントを変換する必要があるならば、まずはそのドキュメントを分割することを考えるべきです。

構文を拡張する方法は用意するべき

構文を拡張する方法は、開発者によって用意されるべきです。その言語から派生した言語が多く出現することを抑制するためです。わずかに異なる言語に新しい名前をつけて普及させることは、その言語を利用するユーザを混乱させることに繋がります。(LML は出力のパターンが少ないので特に注意するべきでしょう。)

拡張された構文であることをユーザに明確に提示することは重要です。あるシステム A で使用できた構文は、あるシステム Bでは使えない、ということをユーザに示す必要があります。拡張構文を定義すれば、ユーザに対し、その構文が異なるシステムでは使えないことを明示することができます。