Syntax design

KARAS のコンセプトや設計方針について解説します。

• 直感的な記号の選択
• 順序付きリストの設計
• コメントアウトの設計
• 改行の設計
• インライン引用文の設計
• テーブルの設計
• ルビの設計
• Blockquote の設計
  • Blockquote の特徴
  • コピーアンドペーストによる引用
  • Blockquote の中の構文
• Footnote の設計
• Plugin Syntax の設計
  • 大文字と小文字を考慮するのは良くない

直感的な記号の選択

構文に使う記号は直感的であるべきです。多くの LML が構文のために直感的な記号を使っていますが、それでも私の十分な要求を満たすものはありませんでした。

/ 記号は斜めに見えるし、% は何かを / でスプリットしているように見えます。 , や ' はどう見ても上の方に書かれていたり、下の方か書かれています。 _ は下線にしか見えないし、 ? はその時点では不明な情報であることを示すために十分な記号です。 ? が意味する最も直感的な意味は、 不明 でしょう。

もちろん習慣的な記号の使い方も重要です。 @ は今日 (in 2014) この記号がどのように使われているかを考えれば理解し貰えるでしょう。 $ は UNIX (LINUX) のコンソールから取りました。 > はメールやコメント欄での会話からです。 ` は既存の LML から取りました。テキストに var や code の意味を与えるユーザは、これまで LML などを触ってきたユーザだからです。

順序付きリストの設計

いくつかの LML は Num. と書くことで、順序付のリストを出力します。この構文は確かに直感的ですが、いちいち数字を書くのが面倒です。 #. と書くことで順序を自動で付けることもできますが、いくつかの記号をリストのために使うことは、 KARAS では考えません。 - と + の出力結果が、それぞれ ul と ol 要素になることは十分に直感的に見えます。そして何よりも、ネストを表現するために空白文字を使いたくありませんから、KARAS の順序付きのリストは + を使います。

コメントアウトの設計

プログラミングなどでは、コメントアウトの構文は // を使います。一方で、KARAS では ## としています。これは斜体となるテキストを表すために // が直感的で優れているためです。 KARAS では、 // を使ってコメントアウトを出力することよりも、 // を使って斜体テキストを出力することを優先しました。 KARAS はプログラマ以外にも、ドキュメントを書く全てのユーザに利用されるべきだからです。 また一部のソフトウェアの設定などで、## が使われていますから、このことは問題にならないでしょう。

改行の設計

改行のデザインについては大変苦労しました。改行を表す記号は、改行の直前に書かれる必要があります。したがって KARAS に定義される他の構文とは異なり、構文の記号が文の中で意味を持たないようにする必要があります。

言い換えれば、改行に使用される記号は、その記号が単独では意味を持たないことが理想的です。例えば & は、記号がそれ自身で明白な意味を持っているため、改行のための構文に使用するのは不適切です。他にも !, @, %, ., , は、同じ理由で不適切です。これら以外の記号から改行を表す記号を選ぶ必要がありました。

設計当初は ^ を改行のために使いましたが止めました。 ^ は正規表現で、先頭を意味するからです。次に、正規表現で末尾を意味する $ を使いました。これは最終直前のバージョンまで使いましたが止めました。最後に追加した kbd 要素、ユーザの入力を表すテキストを出力するための構文に使う良い記号が、他にはありませんでした。最終的には、定義されていた文字参照のための構文を KARAS から取り除き、そのために使っていた記号 ~ を改行の構文に使うことにしました。

インライン引用文の設計

引用の設計は大変悩みました。各国の言語によって引用符として用いられる記号が異なるためです。例えば "" であったり '' であったり <<>> であったりします。設計当初は、言語に応じて引用のために使う記号を変更することも考えました。しかしながら出力結果が環境によって異なることは良くないと思い、直ぐにその案を破棄しました。

最終的には、KARAS では引用文を書くときには "" を使用するように設計しました。ASCII コードの中で、引用という名前を付けられた記号は ' と " です。 ' と , を使って、 super と sub を示したかったので、残った記号である " を、引用文のための構文にしました。

blockquote の構文が > 記号を使うことを考えると、 (Inline)quote の構文も < と > を使うのが良いかもしれないとも考えました。しかしながら、他のインライン構文は、開始と終了に異なる記号を使いません。また記号の形が、強い指向性を示すため、他の構文とは明らかに異なる、特別な意味を持つ構文のために使うことにしました。

• Reference
  • (JPN) 引用符 - Wikipedia

テーブルの設計

テーブルの設計は大変悩みました。プレーンテキストでの見やすさを考慮すると多くの入力が必要になりますし、逆に、入力を簡潔にするとプレーンテキストでは見難くなります。この問題は、他の LML を使用したことがあるユーザにとっては既知の問題でしょう。またテーブルには text-align やヘッダなどの多くのオプションがあります。

私は KARAS を設計するときに、可能な限りいくつかの記号を組み合わせる構文を設計しないように注意しました。構文を簡潔にし、ユーザの構文を学習する負担を減らすためです。しかしながら、テーブルを簡潔に記述するためには、記号の組み合わせがどうしても必要でした。

KARAS では text-align を制御するために <, >, = の記号を使用します。整列方向を示すために、最も簡単で直感的な記号だからです。 < や > がいくつも使われることは、プレーンテキストでのテーブルの見やすさを損なう可能性がありましたが、実際には問題にならないでしょう。整列方向の操作は列か、あるいは行で統一されることが多いです。例えば次のようなテーブルが多いでしょう。

!| Cell 1 |> value |> value
!| Cell 2 |> value |> value
!| Cell 3 |> value |> value

次のように複雑で見難いテーブルを書くことは少ないはずです。したがってテーブルのためにいくつかの記号を使っても、十分に可読性を維持できると判断しました。

!> Cell 1 |= value |> value
|> Cell 2 |< value |= value
!< Cell 3 |> value |< value

また例えば、他のどんな記号でセルを表したとしても、各セルの幅をユーザが任意に調整するなどしなければ、プレーンテキストで書かれたテーブルの可読性は下がるでしょう。これらの理由から KARAS のテーブルは現在のようにデザインされました。

ルビの設計

ルビの文化がある言語が少ないですから、KARAS をルビに対応させるべきか悩みました。覚える必要がある構文は少ない方が良いでしょう。私の母国語である日本語はルビが多く活用される希有な言語です。W3C のドキュメントを読んでも、ルビに大きく貢献しているのは日本人です。事実、2013年11月現在で主要な Web ブラウザの1つである FireFox (Gecko) も現在のバージョンではルビには対応していません。日本の様々な紙面からもルビは少なくなっているのが現状です。しかしながら、最終的には、次に示す理由から、KARAS にルビを出力するための構文を定義しました。

最大の理由は、私が好きな日本の漫画でルビが頻繁に使われているためです。また漫画に限らず、日本の文学作品では、ある語句の示す意味とは別の言葉をルビによって表現することがあります。このような表現の方法は他にありません。この独特の文化を表現するための仕組みが、KARAS の標準的な出力である HTML に取り入れられていることは大変喜ばしいことです。この理由から KARAS にはルビを出力するための構文を取り入れることにしました。

ルビのための構文は、次の2つの条件を満たす必要があります。

1. ルビのために特別な記号を使わない。
2. 素早く簡単に入力することができる。

ASCII コードに含まれる記号の数には限りがあります。したがってルビのためだけに特別な記号を使うことはできません。したがって、KARAS では、上付き文字の上位の構文として設計しました。

また、日本人であってもルビを入力するのは大変面倒です。Word のような WYSIWYG のシステムを使っても面倒です。JIS や青空文庫などの日本独自の文章の規格には、いくつかのルビのための構文が設計されていましたが、いずれも入力が面倒です。いくつかの記号を組み合わせたり、どの文字がルビを持っているのか分かり難いです。面倒だから使わなくなるのです。KARAS はオプションのための構文でテキストを区切るだけで、簡単にルビを使うことができます。

もしも、将来的に、HTML やその他のフォーマットからルビが取り入れられなくなったとしたら、KARAS もルビのための構文を使うことができなくなります。KARAS ではルビを簡単に使うことができるようにしたので、是非使ってください。あるいは、ルビの新しい使い方が展開していくことを期待します。

ルビに関する情報は、日本語の Wikipedia のページか、あるいは W3C のページが詳しく解説しています。

• Reference
  • (JPN) ルビ - Wikipedia
  • Ruby Annotation - W3C

Blockquote の設計

Blockquote の特徴

メールや軽量マークアップ言語の Blockquote の構文は、他の構文と比べて明らかに違うルールを持っています。例えば、リストは、- という記号それぞれが、異なる要素として認識されます。次の例の場合、リストは2つの要素から構成されます。

- Item 1
- Item 2

しかしながら、 Blockquote の場合は異なります。テキストの先頭が > という記号を同じ数だけ持つとき、それは1つの同じ要素としてみなされます。次の例の場合、引用文は1つの要素から構成されます。

> Blockquote text 1.
> Blockquote text 2.

このルールは明らかに他の記号とは異なります。しかし多くの軽量マークアップ言語や、メールのテキストで共通の設計です。他の軽量マークアップ言語では、半角スペースが整形済みテキストを示すとき、そのルールは Blockquote と同じルールです。しかしながら KARAS では半角スペースを用いた構文を用いていないのです。つまりこのようなルールを適用するのが Blockquote だけなのです。

この特徴に気が付いたとき、私はこのような Blockquote の構文は良くないな、と思いました。ブロックグループの構文によって Blockquote を実現する方法も考えました。しかしながら、最終的には、 KARAS はこの伝統を採用しています。理由はこの次の項目で解説します

コピーアンドペーストによる引用

最終的に、KARAS では > が行頭に書かれたとき Blockquote を出力するように設計しました。多くの LML と同じ構文です。この最終的な仕様以外に、 {{ によってグループ化されたテキストを Blockquote とする構文を考えましたが止めました。理由は次の通りです。

Blockquote を必要とするシチュエーションの1つにメールのコピーアンドペーストがあります。メールを引用するときは、多くのユーザがコピーアンドペーストするでしょう。多くのメールシステムでは、引用を表すときに > を使っています。メールのテキストをコピーするとき、 > がテキストの行頭に付いています。したがってペーストした内容をそのまま Blockquote として出力できる仕組みが必要だと考えました。メールを引用するときに、いちいちテキストを書き直すユーザはいないでしょう。

また、必要なら、ユーザは自分で > を書くことができます。 > から始まった連続するテキストは、すべて Blockquote として出力されます。改行の度に > を書く必要はありません。したがって、ユーザが自分で > を書くときも、それほど大きな問題にはなりません。また、メール以外の文章をコピーするときも同じです。 > を1つ書いて、そのあとに続いてコピーしたテキストをペーストするだけです。

Blockquote の中の構文

設計の途中の段階では、 Blockquote の中にある KARAS の構文は変換しないようにしていました。これは、現実的には、引用文そのものにタイトルなどを含めることはあまりないと考えていたからです。しかしながらリストや図などを含めて引用であることを示すためには、 Blockquote 中の構文を変換する必要があります。したがって Blockquote の中の構文を変換するようにしました。KARAS はデジタルで使われますから、将来的には、例えば動画やリストなどをまとめて引用として示すような使い方もされるでしょう。

例えばユーザがある HP に書かれたテキストを引用しようとするとき、ユーザはブラウザに見えるテキストをそのままコピーアンドペーストするでしょう。わざわざ、KARAS の構文に書き直すことはしませんし、KARAS で書かれたテキストがそのまま公開されていることも少ないはずです。このとき、構文がシンプルな LML では、テキストをコピーアンドペーストしたときに誤変換する可能性があります。しかしながら、KARAS の構文は多くが2つ以上の記号を使いますから、誤変換の可能性は少ないでしょう。

Footnote の設計

多くの LML や LML を使うシステムが Footnote の構文を持っていますから、KARAS でも同じことができる必要があると考えました。しかしながら、KARAS は Footnote のための構文を持っていません。KARAS ではリンクの構文と、インライングループの構文を使って Footnote を出力します。以下にそのような設計に至るまでの経緯を説明します。

まずは Footnote の出力方法を考える必要もありました。書かれたドキュメントの一番下にだけ出力できれば良いのか。それがどのように出力されるのか、ユーザは変更できなくて良いのか。 Footnote を表す記号は、ユーザが変更できなくて良いのか。などです。この時点では、要求される機能が多く、設計が難航しました。

しばらく出力方法を考えていると、1つの答えに辿り着きました。 Footnote は、結局のところ、書かれる場所が異なるだけで、 Note と同じです。 Note はあらゆる場所に書かれても良いはずです。そして、 Footnote は2つの特徴を持っています。1つはあるテキストに ID をつけることです。もう1つはあるテキストから、 ID をつけたテキストにジャンプするためのリンクを持たせることです。

KARAS は1つの構文から複数の意味が出力されないように設計しています。(リンクは例外です。) したがって、1つの記号によって成り立つ構文から Footnote を出力することを止めました。また、1つの記号によって Footnote を出力する構文を設計してみました。しかしながら、リンクするテキストと、リンクされるテキストのどちらであるか、判別しにくいという問題がありました。

そして、 Footnote の特徴から、リンクのための構文を利用することに決めました。この決定の後は、設計はスムーズに進みました。実のところ、 Footnote / Note のための構文を設計するまでは、インライングループはテキストに ID を追加するための仕組みを持っていませんでした。しかしながら Footnote / Note を美しく書くために、新たに追加しました。私は、あるテキストが ID を持つことに疑問を持っていましたが、 Note などの目的のために必要であることが分かったからです。

リンクの構文とインライングループの構文を使うことによって、 Footnote や Note のあらゆる要求を満たすことができるようになりました。ただし、自動的に Footnote のリストとそのリンクを生成するような仕組みだけは実現できません。そのような機能が必要なシステムは、Wiki のようなシステムだと思います。そのような場合には、拡張構文を使って対応することができます。

Plugin Syntax の設計

Plugin Syntax が特別な構文であることを明示するために、その構文は Basic Syntax とは明確に異なることが重要です。そこで Plugin Syntax で用いる記号 [ と ] は、 Basic Sytax には含まれないように設計しました。

Plugin Syntax は 主にプラグインや特殊な装飾を目的として使用することを想定しています。それはレイアウトであったり、自動入力であるかもしれません。 Plugin Sytax による様々な操作のために、オプションの値を定義する方法も明示することも重要です。

Plugin Syntax の使用場面は大きく2つです。あるテキストに処理を適用する場合と、独立して処理が実行される場合です。これらの内の何れでも対応できないような問題がいくつか表れるときは、新しい言語の開発を考えるべきでしょう。

大文字と小文字を考慮するのは良くない

Plugin Syntax やそのオプションの指定において、大文字であっても小文字であっても同一の処理が実行されるべきです。ユーザが大文字か小文字かを考えながらドキュメントを書くことは良いことではありません。