Unsupported features

このページでは、KARAS の現在のバージョンで、未対応の要素などについて述べます。

• 新しい構文が必要なとき
• ある人物の発言を示すための構文
  • 関連する HTML の動向
  • 特別な出力のためのマークアップの組み合わせ
• インライン構文のネスト
  • インライン構文のネストの難しさ
• 見出し ID の自動挿入
• KARAS で使われていない記号
  • . 記号
  • & 記号
• KARAS から出力できない HTML 要素
  • wbr 要素と nobr 要素
  • time 要素
  • mark 要素
  • form 要素とそれに関する要素
  • 文字参照

新しい構文が必要なとき

新しい機能が必要な時は拡張構文を使用して解決することを推奨します。あるいは、限定的な使い方であれば、拡張構文を用意するよりもコピーアンドペーストできる HTML タグのテンプレートを用意した方が良いでしょう。

もしかしたら、ある国の特有の言語が重要な特徴を持っていて、それを KARAS を使って記述することができないことがあるかもしれません。そのような場合には、その言語に特有の記号を使って、KARAS の構文を継承した新しい LML を設計することが必要になるでしょう。

ある人物の発言を示すための構文

会話を表す構文は KARAS に定義されていません。これは KARAS の標準的な出力フォーマットである HTML に、会話文を示す方法が定義されていないためです。しかしながら小説などでは名前と発言が1セットになったテキストが現れます。また2012年現在では SNS (Twitter, Facebook, etc…) が流行していますが、これらも会話に近い性質を持っています。これらが将来的に HTML に定義されるとき、これらを KARAS に追加する可能性があります。 Block group として定義することになるような気はしていますが、定かではありません。

関連する HTML の動向

HTML5 では、会話文を示すための dialog 要素を取り入れる案が上がっていましたが、変更され、削除されています。

• Reference
  • (JPN) dialog要素がHTML5から削除されました。代わりにp要素を使う？ - HTML5.JP
  • This Week in HTML5 – Episode 35 - The WHATWG Blog

また HTML5 では、cite 要素は、例え出典を示すためであっても、個人の名前を示すために使用することができなくなりました(以前のバージョン4ではできました)。私はあらゆる意味での引用もとを示すために cite 要素を使用するべきだと考えています。 cite という単語とは本来そういう意味です。むしろ、KARAS のユーザには、 cite 要素を発言者を示すために積極的に利用して欲しいとも考えています (HTML5 では意味が変更されてしまいましたが)。しかし、 人名 を示すために使うべきではないのは確かです。あくまでも 出典 を示すために使用されるべきです。

特別な出力のためのマークアップの組み合わせ

例えば、人物のプロフィールなどを書くための構文があった方が便利だとあなたは思うかもしれません。そのような特別な意味を持つ構文を設計することは、少し待ってください。例えば、人物のプロフィールなどを HTML を使って書くための統一的なフォーマットは、microformats などの団体によって推奨されています。2014年1月現在、十分に普及しているとは言えませんが、これらのような団体が推奨するフォーマットを出力するために、KARAS を使うことができます。

• Reference
  • microformats.org

KARAS はあらゆるドキュメントを簡潔に、簡単に書くことを目的として設計されています。したがって、これらについて対応することはないでしょう。

インライン構文のネスト

変換速度やマークアップされたテキストの簡潔さを優先するため、KARAS はインライン構文をネストすることができません。将来的に、十分に高速に変換する環境が十分に普及すれば、対応するかもしれません。

もしもインラインマークアップをネスト可能にすると、ruby のために新しい記号を使う必要があります。あるいは ruby を削除するかもしれません。 dfn / abbr も同じです。実は abbr を使って略称であることを示す必要があるか、疑問に思っています。略称である、という情報は、あまり使い道がないように思えます。 dfn がネストできるなら、もっと不要になるでしょう。

インライン構文のネストの難しさ

インライン構文のネストの難しさについて、少しだけ紹介します。簡単に言えば、パターン数が多くなるのです。すべてのパターンをユーザが期待するように処理できなければ、その例外のパターンは、ドキュメントに書いてユーザに示す必要があります。そのようなことは、できるだけ避けるべきです。直感的にドキュメントを書くことができなくなります。つまり、そのような設計では、あのパターンはダメだとか、このパターンはダメだとか、そういうことを考えながら書く必要があるのです。

ネストを実装するとき、考慮するべきパターンには、例えば次のものがあります。ここでは () は、構文のまとまりを示しています。例えば、実際には、1 のパターンは、**Text1*****Text*** と書かれていることになります。

1. (**Text1**)(***Text2***)
2. (**Text1(***Text2***)**)
3. (**Text1(***Text2***)Text3**)
4. (***Text1(**Text2**)***)
5. (***Text1(**Text2**)Text3***)
6. (***(**Text1**)Text2***)
7. (**(***Text1***)Text2**)
8. *****Text1*****
   1. (**(***Text1***)**)
   2. (***(**Text1**)***)
   3. (*****Text1*****)

8 のパターンは、8.1 - 8.3 のいずれかのパターンを処理することになります。そして残念なことに、パターンはこれですべてではありません。実際には、記号が閉じられないテキストがあります。さらに、他の記号との誤ったネストは変換しないようにする必要があります。とても難しく、大変な処理です。

見出し ID の自動挿入

Wiki などでは、見出しに ID が指定されないとき、 ID を自動で挿入する機能があります。この機能は特に TOC などを作るときに必要です。しかしながら、KARAS は ID を自動で挿入しません。これは KARAS が軽量マークアップ言語であって、システムそのものではないことが大きな原因です。

例えば、ランダムに ID をつける方法があります。ランダムにつけられた ID は出力するたびに変わります。これが Wiki などのシステムであれば、ID を保存すれば問題はありません。しかしながら、KARAS は軽量マークアップ言語ですから、変更したテキストを保存する機能は持っていません。ランダムに変わる ID は、ユーザがその見出しにリンクするときに、参照できなくなる問題を起こします。

見出しの頭文字やすべてのテキストを ID にする方法があります。この方法は大変便利で、ユーザが見出しにつけられる ID を、認識できるという利点があります。しかしながら、 ID が重複したときは、変更した ID をわずかに変更する必要があります。そのとき、ユーザが重複を認識する方法がありません。

見出しの持つ文字列を ID に使う方法は、異なる問題も持っています。HTML5 では空白文字を除くあらゆる文字が ID に指定できます。しかしながら、現実的には、様々な環境でドキュメントを扱うために、ASCII コードに登録されている文字列で指定するのが良いです。つまり、アルファベットに変換する必要がありますが、すべての文字列をアルファベットに変換すると、 ID は長くなります。(無駄です。) 一方で、ある単語や先頭の数文字をアルファベットに変換するためには、各国の言語について、十分な知識が必要です。KARAS のコンバータにそのすべてを実装することも現実的ではありません。

他に、順に数字を付けていくことも考えましたが、ここで紹介した問題と同じ問題を持っています。 ID の自動的な決定は、需要があることは分かっています。将来的に、これらの問題を解決できる本当に素晴らしいアイデアがあれば、この機能を導入します。それまでは、必要なら、KARAS を導入するシステムが独自に ID の自動挿入を実装してください。ランダムでも良いでしょう。

KARAS で使われていない記号

KARAS の構文で使われていない ASCII コードの記号は ^ と . と & と半角スペースです。これらは、将来的には、新しい構文を定義するときに使うかもしれません。

. 記号

記号 . は、ファイルパスや URL などで多く使われるために、KARAS では使われていません。例えば .. は、コンピュータでは、1つ上の階層を示す相対パスとしてよく使われます。ファイルパスや URL はコンピュータにおいてとても重要ですから、可能な限り誤変換をなくしたいと考えました。したがって KARAS は . 記号を使う構文を持っていません。

. 記号を行頭に書いて使う構文を定義すれば、誤変換を回避することができるでしょう。しかしながら . はあまりに小さく、見にくいので、採用を見送りました。

& 記号

記号 & は、文字参照を表すテキストの先頭に書かれるテキストなので、KARAS では使われていません。 現実的に、文字参照はどのような形式のドキュメントにも必要です。ある連続する & 記号が、文字参照を表すのか、構文を表すのか、解析することは大変です。したがて KARAS は & 記号を使う構文を持っていません。また同じ理由で 記号 ; は、インラインマークアップとして使いません。

KARAS から出力できない HTML 要素

wbr 要素と nobr 要素

KARAS では wbr 要素と nobr 要素を出力するための構文を持っていません。KARAS はドキュメントの生成を目的にしているからです。改行はドキュメントに意味を持たせる可能性があります。しかしながら、改行許可や改行禁止はドキュメントに意味を持たせる可能性が低いと判断しました。またいちいち改行を許可する位置や許可しない位置を考えてドキュメントを書きたいでしょうか。答えはノーです。

KARAS では、あるドキュメントを改行するかしないかは、ブラウザなどのユーザエージェントに任せます。将来的にも対応することはないでしょう。(仮に対応してもドキュメントの簡潔さが失われることは必至です。)

time 要素

time 要素は、対応方法を用意する必要があるかもしれないと考えています。一方で、time 要素として記すべき情報のほとんどは、システムが自動で挿入するべきであるため、不要であるとも考えています。最終的には、KARAS の現在のバージョンでは time 要素を出力するための構文を持っていません。

確かに、ドキュメント中に time 要素を使いたいときがあります。例えば何かが起こった日付を示す場合などです。しかしながら time 要素は曖昧な情報を示すために使うべきではないと W3C は提唱しています。多くの場合に、ドキュメント中に書かれる時間情報は、正確に書かれないでしょう。例えば 昨日 や、 2014年1月現在 などです。あるいは、その国の言語では正確に書かれた時間情報でも、プログラムが解析できない形式であれば、それは W3C の提唱する条件は満たさない点にも注意が必要です。

整理すると、重要な項目は2つです。(1) 曖昧な時間情報を示すために time 要素が使えない。 (2) プログラムが解析できるような時間情報を示すように変換しなければならない。この2つを考慮したとき、KARAS に time 要素を出力するための構文を設けることを止めました。また time 要素を HTML タグを使って書くことはそれほど大変な作業ではないでしょう。

将来的に time 要素が曖昧な時間情報を示すために使うことができるようになったり、あるいはそのための要素が HTML に定義されたりするとき、time 要素を出力するための構文を改めて検討します。もし定義するなら、 @ を使って、レベル1を time要素、レベル2を cite 要素、レベル3を small 要素とするでしょう。しかしながら、その時には他の要素も新しく定義されるでしょうから、この構文が採用されることは約束できません。

mark 要素

私は mark 要素は、ドキュメントを書く人が提供するべき情報を持たないと考えました。私は mark 要素を使う方法に対して様々な見解があることを知っていますが、KARAS が将来的に mark 要素を出力するための構文を取り入れることはないでしょう。

あるドキュメントが重要であることを示すためには b, strong, i, em 要素があります。もしもテキストを装飾したいのであれば span 要素を使うことができ、KARAS には span 要素を出力するためのインライングループ構文があります。テキストを区別するための仕組みは十分に提供されています。一方で、ドキュメントを書いたユーザ以外が区別したテキストを、明確にするための方法は他になりません。これだけではありませんが、そのような目的のために mark 要素を使うべきだと考えています。

form 要素とそれに関する要素

KARAS はドキュメントを作成する目的で作られていますから、 form 要素やそれに関する要素に対応する予定はありません。将来的にも対応することはないでしょう。

文字参照

構文の最終的な決定の直前のバージョンまでは、KARAS は文字参照を出力するための構文を持っていました。文字参照の構文を用意することで、ある特殊な文字を書くために、その文字の文字参照を調べる必要がなくなると思ったからです。しかしながら、最終的には、KARAS からは文字参照のための構文は取り除きました。(実際にプロトタイプでは実装もしていたし、マニュアルも書いていました。)

取り除いた理由はいくつかあります。最近(2014)のブラウザなどのユーザエージェントは、そのユーザの国の言語の特殊な文字を、そのままに出力できることが多いです。さらに、そのような出力ができないときは文字参照を使っても出力できないことが多いでしょう。将来的には、文字参照を使わなくてもテキストを表示できるようなユーザーエージェントが増えるでしょうし、私はそうなることを期待しています。また、文字参照が必要な文字がテキストの中に含まれていたら、プログラムがそれを自動で変換するべきです。

記号の数が足りなくなってしまったことも原因の1つです。同じ時期に、KARAS に kbd 要素を取り入れることを考えていました。それまでに設計したすべての構文を改めて見直しましたが、ベストな設計のためには記号が足りませんでした。文字参照の必要性を疑っていた私は、この時点で文字参照のための構文を捨てることを決意しました。