# Design ## ドキュメント ### ソーステキストファースト ドキュメントの可読性の基準はソーステキスト(Markdownテキスト)でありレンダリング後の可読性はオプションである。 よって構文はレンダリングを要さず直接意味付けの役割を果たさなければならない。 ゆえにすべての構文は直感に従い意味を解釈できる。 ### ドキュメント指向 ドキュメントはHTMLドキュメントに要求される人的操作性を損なってはならない。 よって構文は次の操作的機能を備えなければならない。 - 参照性 - 主要項目を識別子により参照可能である - 編集性 - 主要項目の識別子を任意の識別子で固定可能である - 識別子は記述位置に依存せず可搬である ゆえに構文は識別子の設定および参照構文を備える。 ### 全文展開 ドキュメントはその全文の閲覧のために追加の操作を必要としてはならない。 よってドキュメントはその全文を展開して表示しなければならない。 ゆえに構文はレンダリング後の操作により表示する内容および状態を変化させる構文を備えない。 ### モノクロプリント対応 構文はモノクロ表示および印刷に対応していなければならない。 ゆえに構文はCSSにより次の通り表示を変更することで意味付けを維持したままモノクロ版に変換できる。 |Syntax|HTML |Presentation |------|-------|------------ | == |\|マーカー(薄灰) | ++ |\ |下破線 | ~~ |\ |打消線 ### 閲覧者によるマークアップ方法の確保 構文およびその表現は閲覧者による基本的なマークアップを妨げてはならない。 ゆえに構文は下線、打ち消し線のための構文を備えない。 ハイライトは閲覧者によるハイライトを妨げないよう線幅が40%以下かつ淡色でなければならない。 閲覧者によるマークアップはベースがカラーの場合は下線、モノクロの場合はモノクロ版に変換のうえマーカーにより行うことを企図している。 ### ユニバーサルポータビリティ ドキュメントは異なるサイトやツール上でも一貫して表示されなければならない。 よってパーサーの構成は固定でなければならない。 またリンクは固定できなければならない。 ゆえにAPIはパーサーの構成を変更できない。 また非従属コンテンツへの相対リンクはドメインを固定できる。 ### 自己完結性 ドキュメントはすべて初期(共通)構成の閲覧環境で閲覧できなければならない。 よって閲覧に拡張機能等の追加が必要となってはならない ゆえにドキュメントはサードパーティツールなど自己完結性を損なうツールの使用をサポートしない。 また自己完結性を損なうエコシステムを構築しない。 ### サードパーティドキュメントの共有および表示可能性 ドキュメントはそのセキュリティ上の信頼性にかかわらず共有および表示できなければならない。 よってパーサーおよびレンダラーはXSSをはじめとする悪意あるコードの注入に対して安全でなければならない。 #### XSS安全 パーサーはパース結果をオブジェクトとして生成しHTML等の文字列での表現を経由しない。 ゆえにパーサーはXSS安全である。 ただし外部メディアの表示等安全性を外部サービスに依存する部分はこの限りではない。 #### Fishing安全 パーサーはリンクテキストとリンク先の一致しないリンクを生成しない。 ゆえにパーサーはFishing安全である。 #### DOS安全 パーサーは入力文字列により実行環境を応答不能にすることはない。 ゆえにパーサーはDOS安全である。 ##### インプットサイズ パーサーは上限を超えるサイズの入力をパースしない。 また上限を超えない入力は1秒以下でセグメントに分割され非同期での逐次パースが可能である。 ゆえに入力はパーサーの実行環境を応答不能にすることはない。 ##### セグメントサイズ パーサーは上限を超えるサイズのセグメントをパースしない。 また上限を超えないセグメントのパースも規定のパースコストの上限を超えない。 ゆえに入力はパーサーの実行環境を応答不能にすることはない。 なお1セグメントは1ブロックに対応する。 ##### パースコスト パーサーはパースコストが上限を超えるセグメントをパースしない。 パースコストは同一セグメント内で内部セグメントの境界を超えて共有されるため内部セグメントが存在する場合もこの制約は保たれる。 ゆえにセグメントは過大な入力または過剰なバックトラックによりパーサーの実行環境を応答不能にすることはない。 なおこの上限は非常に高く設定されており通常の使用で上限を超えることは考えにくい。 ### 情報通信フォーマット 以上のようにSecuremarkは(ドキュメント形式、すなわちインテリジェンス化された)情報の伝達および共有を要件として設計された情報通信フォーマットである。 よってこの能力を失わせる変更を行ってはならない。 ## 構文 ### 引用文可搬性 引用構文はコピー＆ペーストにより挿入されたテキストを無編集で使用できなければならない。 ゆえに引用構文は引用文をパースしない。 ### 改行不変性 改行は表示文字列とこれを入力とする再出力で不変でなければならない。 ゆえに改行は入力と出力で一貫することを標準とする。 ### オートリンク不変性 オートリンクは表示文字列とこれを入力とする再出力において解釈が不変でなければならない。 ゆえにハッシュタグ構文は構文が表示文字列と一致する構文であるオートリンク構文(`#tag`)としてのみ構文化され、表示文字列から構文の範囲が特定不可能となる通常構文の形態(`#{tag}`)を持たない。 ### 自動附番 ドキュメント内の参照はドキュメントの編集を妨げないよう参照先および参照元いずれも記述順序に非依存でなければならない。 ゆえに参照箇所に実体を記述する注釈構文および識別に文字列を使用する図表構文を採用し、その表示方法は任意とする。 脚注構文は附番が手作業となり参照と実体の対応の管理が困難であるため不採用とし注釈構文により生成可能とする。 ### アクセント設定 ドキュメントは漫然と読まれないよう緩急をつけられなければならない。 よって構文は他の構文に続けて漫然と読み流せない異質な視覚表現を持ちアクセントとなる構文を備えなければならない。 なおこのためアクセント構文は他の構文と完全に統一されたデザインであってはならず若干異質なデザインでなければならない。 ゆえに構文は着色およびデザインにより視覚的刺激を与えるMessage構文を備える。 またAside構文は関心の変化により認知的刺激を与える。 ### 羅列的知識への非依存 構文はその使用のために羅列的知識を求めてはならない。 ゆえにバックスラッシュエスケープの特殊処理の対象は改行文字のみに限られる。 またURL構文はHTMLエンティティの参照の有効性を検査しない。 HTMLEntity構文はエンティティ追加時の互換性確保のため不正なエンティティを検出する。 ### テンプレート対応 ソーステキストは自身をテンプレートとして別のソーステキストを生成するための構文を使用できなければならない。 またテンプレートとなるソーステキストもドキュメントとして正しく表示できなければならない。 よって構文はテンプレートのソーステキストとドキュメント間での表示上の一貫性のための構文を備えなければならない。 ゆえに構文はテンプレート構文を備える。 ### 編集中のソーステキストのレンダリング結果の表示安定性 レンダリング結果の表示はソーステキストの編集にともなう高頻度または広範囲にわたる変化により視覚的負担をかけてはならない。 よって構文は編集過程で生じる不完全な構文を最大限補完してパースしなければならない。 ゆえにすべてのブロック構文は順次的編集過程で生じるすべての不完全な構文を補完してパースする。 またインラインのレンダリングに含まれる高価な処理はキャッシュにより即時化される。 ### 構文階層独立性 上位区分の構文の一致は下位区分の構文から独立して上位区分の構文の形式のみから判定されなければならない。 よって上位区分の構文の一致判定に下位区分の構文による内包文字列のパース結果を用いてはならない。 ゆえにすべてのブロック構文は構文の一致判定にインライン構文による内包文字列のパース結果を用いない。 またすべての構文は任意の包含関係において無効化および有効化できる。 ### 構文不変性 任意のソーステキストの中で構文に一致する文字列は構文の拡張の前後において不変でなければならず追加の前後において最大限不変でなければならない。 よって構文の属性等のパラメータは値でなく書式で制約しなければならない。 また不正なパラメータまたは構成の文字列は誤入力および出力の将来的可変性を通知するパース結果を出力しなければならない。 ゆえにすべての構文はこのように実装される。 ### 構文追加要件 構文の追加は原則として次のいずれかの要求に対応するものでなければならない。 - HTML上の情報表示形式への対応(\
    など) - HTML上で固有の視覚表現を持つ意味付けへの対応(\など) - HTMLドキュメントに要求される操作的機能の充足(Index構文など) よって外観や制御のために構文を追加してはならない。 また他の構文と同じ視覚表現で異なる意味付けを行うHTMLタグを追加してはならない。 ディレクティブなど文書でなくページを記述するための構文を追加してはならない。 ### クラス化制約 他の構文を内部構文として包含可能な類似の構文は先行する構文の解析結果を利用してバックトラックを抑制できるよう構文を先行する類似構文のサブクラスおよび後行する類似構文のスーパークラスとして設計しなければならない。 ## スケーラビリティ パーサーおよびレンダラーはドキュメントサイズの増大により以下の利用性を損なってはならない。 ### 閲覧性 ドキュメントは即時ないし順次閲覧できなければならない。 よってドキュメントは全体のパースを待たず一定時間内に表示を開始しなければならない。 また高価な処理は必要時まで遅延しなければならない。 ゆえにパーサーはパースおよびその結果の返却を逐次的に行う。 またパーサーは外部リソースのリクエストその他の高価な処理を自身で行わずレンダラーに委ねる。 ### 参照性 ドキュメントは各要素への参照、参照先への移動、および参照元への復帰方法を提供しなければならない。 ゆえにドキュメントはすべてのセクション、用語定義、図表、注釈、および出典をリンクを介して参照、移動、および復帰できる。 ### 編集性 ドキュメントはそのサイズにかかわらず編集が容易でなければならない。 よってパースおよびレンダリングは差分更新により行わなければならない。 ゆえにパーサーは差分更新を行い、構文はこのために空行によるブロックの分割を必須とする。 ## 記号解釈 ソーステキストを直接読む際の記号解釈。 ### \# 定義付き語句。 ### ~ 同値的関係。 ### : 説明。 ### ^ 参照識別子。 ### ! 解釈指示。 ### $ 数学的構文。 ### [ ] 指示対象指定(構文の指示部分の括弧が後続する場合)。 対象は必ず可視の文字または要素から始まる。 対象部分(角括弧)は常に指示部分(波または丸括弧)に先行する。 ## 備考 ### AST(CST) Securemarkはブロック単位の差分更新によりリアルタイムレンダリングを高速化しているがCSTを生成する場合行の追加削除により以降すべてのノードの位置情報を更新する必要が生じ許容範囲を超える遅延が生じる可能性がある。このためこの最適化を行う必要があるが行位置の更新のみであればこれのみを行う処理経路の追加は容易であろう。Markdownでも行数は数万行以下と想定できることから行数を全ノードに直接記述せず行ノードの行数を参照する実装に変更すれば更新対象を数万以下の行ノードだけに局限できる。これらは数百行以下に規律されるソースコードにおいては生じない問題であり数十万文字を許容しなければならないマークアップ言語に新出の問題であるため新規にCSTの設計および運用を再考する必要がある。 またBlockquote構文を内包テキストまでシンタックスハイライトする場合、構文(>)と内包テキストが垂直に分割されるため構文と1対1で対応する単純なノードではCSTを表現できず構文の断片を表現するノードが必要となり、さらにこれをエディタ上でシンタックスハイライトするためのHTMLに変換する際に各行においてこの断片のCSTを断片のHTMLに正しく変換および表示しなければならずかなり煩雑な作業を要する。 ### バックトラック バックトラック後にしか到達不能な構文はバックトラックなしに定義不可能。従って他の構文をバックトラック後にしか到達不能にする構文をバックトラックを発生させず追加することも不可能。共通構造を利用してバックトラックを回避する場合も事前に共通構造解析が必要なため複数回解析が必要であり計算量的におよび本質的にバックトラックしているのと変わりない。 - `[[A` -> `[A` -> `A` - `{{A` -> `{A` -> `A` 本質的に括弧として解釈できる記号は開放可能構文と見なして予言的構文として定義することでバックトラックを回避できるがそうでない記号は回避できない。 - `"A` -> `(A` - `` `A `` -> `(A` - `$100` >< `(100` CommonMarkは初手設計ミスったせいで構文一つで最悪計算量32nを叩き出す最悪計算量O(n\*32^m)のクソ言語になり拡張性がなく終わってる。 SecuremarkのReference構文に典型的であるように文脈を変更する構文の中にその文脈に依存し変更される他の構文が存在する場合文脈の相違から解析結果を再利用不能(`αAβ | αA'B`)なバックトラックが生じる。またこの結果再帰的バックトラックが生じる可能性があり再帰的バックトラックは一般的にメモ化により解決されるがCommonMarkは最小計算量と実行性能を追及するためメモ化を廃止していることからメモ化により性能を低下させてまで文脈依存構文の問題を解決するつもりはないと思われる(すなわちCommonMarkは機械を至上とし人間に制約を課す低水準の言語であり人間の需要と生産性を至上とする高水準の言語であるSecuremarkの対極に位置する)。従ってCommonMarkは再帰的バックトラックなしで解析可能な構文と最小計算量に制約され基本的に再帰的バックトラックが生じるものである文脈依存構文を追加できないという拡張性の欠陥が存在する(CommonMarkは文脈を変えず`*A*`の記号と解釈を変更しただけの`~~A~~`のような文脈自由構文は容易に追加できるが他の構文を包含可能な文脈依存構文はリンク構文で発生している再帰的バックトラックまたはその修正のために激増した計算量を組み合わせ爆発により指数関数的に致命的に悪化させるため追加できない。例えばすでに最悪計算量32nであるリンク構文を包含した追加構文が1回バックトラックするだけで最悪計算量が32n\*2=64nに悪化し追加構文がリンク構文と同じく最悪計算量32nなら全体の最悪計算量は32n\*32=n\*32^2=1024nとなる。すなわちCommonMarkの最悪計算量は再帰的バックトラックが生じる構文の数mに対してO(n\*32^m)と驚異的かつ絶望的に劣悪な計算量であり構文数が一つであろうと自己再帰可能ならば入れ子数mに対して同じくO(n\*32^m)となる。なお一般的に実用可能な計算量の上限はO(n^3)であるためCommonMarkは文脈依存構文数または入れ子数m>3になるだけで実用可能な計算量の上限を超える。すなわちCommonMarkは自己再帰可能な文脈依存構文を定義することが不可能である。この事実に開発開始から数年後に直面し再帰数の上限を32回に制限することで指数計算量を防ぐも依然として32nという非常識な計算量になっているのがリンク構文とイメージ構文である。なおリンク構文とイメージ構文を入れ子にできているのはイメージ構文を入れる角括弧部分が文脈自由部分だからであり文脈依存部分である丸括弧部分は入れ子になっておらず文脈依存部分の入れ子が生じていないからである。しかし文脈依存構文を追加してリンク構文を包含すれば丸括弧部分を包含し文脈依存部分が入れ子になり計算量の爆発を避けられない)。CommonMarkの仕様策定者が構文の拡張に(名称を維持するか否かにかかわらず)不自然なまでに消極的であり進展がないのは正当な理由や単なる怠慢からでなく構文追加可否を議論すればCommonMarkは理論的欠陥により最悪計算量が絶望的に劣悪であるため文脈依存構文を追加できないというCommonMarkの設計の破綻と失敗が明らかになることが避けられないためおよび最小計算量を放棄して現在の高い実行性能を低下させたくないためであり陳腐な自尊心を守るためにこのような計算量と拡張性の根本的欠陥を秘匿しCommonMarkとその仕様策定者である自分の評価が下がらないよう画策しているからである。でなければこの計算量と拡張性の根本的欠陥を何年も隠蔽せず速やかに公表して助力を求めていなければならず不都合な事実を隠し陳腐な自尊心を守るために全Markdown利用者および開発者を不必要に足止めした罪は重い。 CommonMarkは小さく単純であるうちだけ破綻せずに正しく見せかけられる象牙の塔であり仕様策定者はこの見せかけの正しさを失わず正しいままでいたいがために象牙の塔に引きこもり小さな表面的正しさに固執し続けているに過ぎない。しかしCommonMarkは実際にはすでに致命的に破綻しており本来文脈依存言語であるMarkdownを文脈自由言語として解析しようとして失敗したことで指数計算量(正確には指数計算量より悪い階乗計算量)になっており実際のところCommonMarkは最初から最後までずっと壊れている。CommonMarkは可能な限り文脈自由言語として設計することでバックトラックなく最小計算量で解析しようとしているが実際には文脈依存言語であるMarkdownから文脈依存構文を文脈自由構文に変換して再帰的バックトラックを除去することに失敗しているためCommonMarkは最初の数年間は再帰的バックトラックに気づかず最悪計算量が指数計算量になっており修正後も依然として最悪計算量が当初の想定の1nから32nへと劇的に悪化している(より正確にはCommonMarkは少なくともCode構文とHTML構文により+2nされるが説明の簡略化のため省略しこれら以外のInline構文のみを比較する)。CommonMarkが最初の数年間他人に指摘され修正されるまで指数計算量であった事実(https://github.com/commonmark/cmark/commit/45f4fc9b917c11221aa03e70a41e3046335a235d)はCommonMarkが初歩的な再帰的バックトラックの原理すら理解していないド素人により設計された素人仕事である事実を証明しておりたかが強調構文の解析のためにメモ化を行い(https://github.com/commonmark/commonmark.js/commit/6d7d6cf150dedb53b7f0972b79313df3364ebbed https://github.com/commonmark/commonmark.js/blob/ac8529c9f55da7fdc1186e3f34313cf411de6e71/js/stmd.js )他人にメモ化を使わない正しい実装に修正された事実(https://github.com/commonmark/commonmark.js/commit/8837f199608ac2e321f75653736747b1e692072f)もまたCommonMarkの仕様策定者がその任に堪える能力のないド素人である事実を証明している。スタックを使う代わりにメモ化するド素人の能力を誰が擁護できるのか？ド素人が作った結果初歩的な再帰的バックトラックすら他人に指摘されるまで気づかず修正後も最悪計算量が32nにまで著しく悪化した設計が正しいと言えるのか？不可能である。一貫してド素人により設計開発仕様策定されているCommonMarkは仕様策定が停滞し未だに1nの最小計算量に固執しているがそんなものはCommonMarkの破綻と失敗が露呈するを恐れて隠蔽しまたとっくの昔に破綻している最小計算量のための設計に未練がましく執着しているだけである。32nという最悪計算量は適切に設計し計算量が抑制された文脈依存言語の最悪計算量より悪く最初から文脈依存言語として適切に設計するほうが自然で破綻がなく拡張性を確保できていた。たった一つの構文だけで最悪計算量が32nも増加するクソ言語に拡張性がないことは明らかである。さらにSecuremarkは再帰的バックトラックを予め対策して設計されているため文脈依存構文数が増えても最悪計算量はたかだか構文数に比例して線形にしか増加しないのに対してCommonMarkは再帰的バックトラックに根本的対策を取れないため文脈依存構文数が増えると最悪計算量が指数関数的に致命的に爆発する。または計算量を組み合わせ爆発させないために文脈依存構文の入れ子使用を制限する、存在自体が破綻と失敗の宣言に等しい制限が必要になる。文脈依存構文を強引に文脈自由構文として解析しようとして失敗したために最悪計算量が当初の想定の1nから32nに劇的に悪化し結局文脈依存言語の妥当な最悪計算量より悪い水準に落ちていることおよび文脈依存構文を追加すると最悪計算量が指数関数的に悪化することから文脈自由化に失敗したCommonMarkの破綻と失敗は明らかでありCommonMarkは文脈自由構文に固執せず最初から多少の文脈依存構文を許容するよう設計しなければならなかった。実際には文脈依存言語であるにもかかわらず文脈自由言語の範囲でしか構文解析できなければ構文解析が破綻し構文が増えるほど破綻が拡大することは自明でありすでに破綻済みで失敗済みのCommonMarkに未来などない。文脈依存言語であるMarkdownに対して文脈自由構文解析器として作られたCommonMarkは最初から開発戦略と技術選択を間違え失敗しており最初から破綻していた。CommonMarkが文脈依存言語を文脈自由言語として最小計算量で解析するために使用した手法は邪道の小手先の技術に過ぎずCommonMarkは邪道を選んだ挙句失敗に終わったのである。文脈依存言語を文脈依存言語のまま解析する正道を選んだSecuremarkが正着し文脈依存言語を文脈自由言語に歪める邪道を選んだCommonMarkが失着に終わったのは当然の帰結であり最初の解析戦略時選択の時点で決まっていたことである。文脈依存言語であるMarkdownを文脈自由言語として解析しようとした結果行き詰ったCommonMarkとその閉塞に技術的合理性はなくCommonMarkは最初からの失敗していた過去の遺物であり廃棄すべき負債である。CommonMarkに動きがないのはすでに破綻しており死んでいることに気付かれないように死んでいるからに過ぎない。このようにCommonMarkは完全に破綻し失敗に終わっているためCommonMarkの拡張や発展を期待しても無駄であり既存の文脈依存構文の最悪計算量を健全化し新たに文脈依存構文を追加可能な拡張性の高いMarkdown仕様は新しく作り直さなければ作れない。しかしCommonMarkの仕様策定者は独自の新しい仕様においても依然としてMarkdownを文脈自由化して文脈自由言語として設計しているため文脈依存構文を追加すると指数計算量になり救いようがない。しかもその構文と仕様は機械可読性を至上としているため非常に醜く人間が書くことも読むことも困難で人間に対する実用性が欠如している。 Securemarkはスーパークラス構文が解析に失敗した入力をサブクラス構文で解析しないことにより再帰的バックトラックを回避する(解析中の構文自身はスーパークラスとサブクラスの両方に含まれるものとする)。スーパークラス構文A(`αAβ`)の解析が失敗すればサブクラス構文B(`α'Aβ'`)の解析も失敗することは自明であり試みるまでもなく解析を省略できる。これは二つの構文の文法が生成する各言語空間がスーパーセットとサブセットの関係にあるならスーパーセットの言語空間の外にある文字列はサブセットの言語空間の内に入る余地がないことからも自明である(この解析法は事前解析によっても可能だが文脈内外のオートリンクURLの括弧解析などを高速に行うこともバックトラックなしで解析することも困難であり本解析に近い解析コストを要するためMarkdownをこの事前解析により高速化することは難しい)。メモ化は解析結果の再利用による高速化の副次的または追加的効果として再帰的バックトラックを回避しているのでありメモ化は再帰的バックトラックを回避するだけなら過剰であり不要である(メモ化はバックトラックがなければ使用されないためバックトラックが少ないほとんどの入力に対してはほとんど使用されず無駄であり空間計算量を不必要に常時数倍以上増加させることから構文解析において必須にも標準にもできない。再帰的バックトラック回避のためにメモ化するとバックトラックなしで解析可能な場合も常に不必要に空間計算量が増加し平均計算量が有意に悪化することがメモ化の最大の欠点である(この問題は解析失敗時のみメモ化すれば解消可能のはずだが基本的にはこうなる)。特に文脈自由構文解析器におけるメモ化の使用は完全に無駄でありバグである。バックトラックが発生しないか他の方法で解決されるならば使用されず破棄されるメモ化は無駄である。複数の文脈で解析結果が同一である文脈独立性のある構文ならメモ化した解析結果を異なる文脈で再利用でき有用だがそのような構文は基本的に少数であるため効果が限定的であり最悪計算量は改善されない。文脈依存構文の解析を困難にするメモ化のコストの重さは解析に本来不要な高速化のために生じておりメモ化からバックトラックがない通常時も常時高コストで低速化し平均実行速度とスループットを低下させるバックトラック時限定の不要な高速化とこのためのコストを除去すれば再帰的バックトラック回避機能だけを低コストで標準的に使用しこれまで高コストであったため敷居が高く使用困難であった文脈依存言語を低コストで手軽に定義および解析できるようになる。もうCommonMarkのように低機能のくせに最悪計算量が劣悪で拡張不能なクソ言語を我慢して使い続けなくてよくなるのである)。この解析法により、CommonMarkならば最悪計算量がn\*32^5=33,554,432nとなる拡張Markdown言語をSecuremarkはメモ化なしで5nの最悪時間計算量で解析している。言語差を考慮せず直接比較してさえ単純なCommonMarkの最悪計算量32nに対して複雑なSecuremarkは5nに過ぎずSecuremarkはCommonMarkより最悪計算量が非常に小さい。またSecuremarkはメモ化を行っていないため空間計算量も小さい。時間計算量と空間計算量を合わせてO(n, n)と表記すると文脈依存言語の通常の最悪計算量はO(n^2, n)、メモ化により効率化できた場合もO(nm, nm)(S(m)>=m byte)(解析結果の位置や構文木等を記録するため空間使用量S(m)>はm byte以上となり数値一つやポインタ一つだけでも8byteを消費する)に過ぎないがSecuremarkのマーキング法はO(nm, nm)(S(m)=m bit)(解析の失敗フラグしか記録しないためS(m)=m bit。また包含文字列を含め全体でn byteの構文1つに対して解析結果の構文木を保持するメモ化は少なくとも構文木のサイズn byteを消費するがマーキング法のメモリ消費量は構文全体のサイズにかかわらず1bit固定である。よって100KBの構文1つに対してメモ化は100KB以上消費するがこの場合もマーキング法は1bitしか消費しない。なお成功フラグによる解析は成功フラグがないのが失敗したからか未到達だからかを判別するための情報と処理が追加で必要になり処理が複雑化しさらに成功フラグは解析のほとんどを占める成功した解析に対してメモリ消費と追加処理が発生し解析効率が全体として悪化するが失敗フラグは少数の失敗した解析でしか解析効率が悪化しないため失敗フラグを記録するほうが全体および平均として解析効率が高く優れている)と極めて効率的であり最も優れている。以上のようにSecuremarkの構文解析アルゴリズムの優位性は理論と実践いずれにおいても圧倒的である。現在のSecuremarkは開発効率と安全性優先の実装により実行性能が大きく低下しているがクライアントで個別のユーザーの操作に応じるには十分高速であるためクライアントで解析するなら解析の効率または速度が実用上問題となることはなく仕様が固まり実行効率優先の高速な実装に移れば他の環境での懸念もないだろう。またSecuremarkの再帰数制限はパーサーコンビネーターの使用による再帰的関数呼び出しに対する実装方式依存の制限であるため計算量と無関係であり再帰的関数呼び出しが生じないよう書き換えれば再帰数制限もない。従ってCommonMarkは再帰上限数と最悪計算量が一致し再帰上限数32回と最悪計算量32nが一致するがSecuremarkの最悪計算量は再帰上限数が100回だろうと100万回だろうと5n固定である。SecuremarkをCommonMarkのような再帰数制限のない実装に変換することは設計上および理論的に何の問題もないがCommonMarkをSecuremarkのような正常な文脈依存言語解析器に変更することは現在の異常な解析規則の破壊的変更による修正なしに不可能である。具体的には二重リンク`[[]()]()`を解析するときCommonMarkはバックトラックと計算量を最小化すべく文脈自由構文解析器として設計されているためリンク構文内をリンク構文が定義されていない異なる文脈として解析せず外側のリンク構文の解析を破棄して内側のみリンク構文として解析するがSecuremarkは文脈依存構文解析器とし設計されているためリンク構文内にリンク構文が定義されておらず外側のみリンクとして解析し他のMarkdown構文解析器もこのように解析しなければならない(ここでCommonMarkはリンク構文`[]()`のバックトラック除去ひいては文脈自由化に角括弧部分`[]`に対しては成功したが丸括弧部分`()`に対しては失敗したことで最悪計算量が指数計算量ないし32nに悪化した。リンク構文を本来通り文脈依存構文として解析すればリンク構文の最悪計算量が2nとなり角括弧部分に限っては1nから2nに悪化するが丸括弧部分は32nから2nに著しく改善する。ここがCommonMarkの根本的な欠陥と失敗が最も明瞭に表出している部分である)。この問題はイメージ構文においてさらに顕著でありリンク構文と同じ問題が正当な表現`![![]()]()`で発生しさらにHTMLのaltはプレーンテキストとして表示されるためMarkdownのaltもプレーンテキストとしてそのまま表示されなければならないにもかかわらず文脈を一致させ再帰的バックトラックを防ぐためにMarkdown文字列として解析しaltに`*a*`と書かれたものを`a`に不正に変換して表示する。無論新しい文脈依存構文を追加する場合も同じ制約が永遠についてまわり構文内文字列をMarkdownとして解析する文脈依存構文においてこの制約を破ると最悪計算量が32\*2^mないし32^mで指数関数的に増加する。すなわちCommonMarkは文脈依存構文を追加すると最悪計算量が32\*2^mないし32^mで指数関数的に悪化するという拡張性の致命的欠陥が存在する。こんな最悪計算量が32^mで組み合わせ爆発する欠陥言語を拡張できるわけがないことはもはや明白である。また大多数のプログラミング言語を見ても明らかなように文脈依存言語は構文内で使用可能な構文を定義しその他の構文は使用できず例外処理するのが通常でありCommonMarkのように本来使用不能な構文を外側の構文を無効化して使用可能に変える異常な言語はほとんどの人間はCommonMark以外に見たことがないだろう。ほぼすべての人間において他のすべての言語が同じ一貫した規則を持ち同じ規則で統一的に使用できるのに対してCommonMarkだけが他と異なる異常な挙動をして使用者に認知的負荷をかけるのである。破壊的変更を避けるため旧構文だけ従来通り文脈自由構文として解析し新構文を文脈依存構文として解析すればキメラ的な非常に不自然かつ歪で一貫性のない解析規則によりCommonMarkという一つの言語の中だけでもユーザーを混乱させるものとなり旧構文で使用した苦肉の策を不必要に新構文でも使用して一貫させれば文脈依存言語なのに文脈自由言語の苦肉の策の解析規則で解析されるこれもまたキメラ的な非常に不自然かつ理論的に設計ミスが明白で実用的にも認知的負荷の高い言語となる。正しく設計された言語と解析器にはありえないこのような解析規則の根本的不整合はその不整合の存在そのものが言語と解析器が誤った設計による失敗作であることを証明しており不整合が存在する限りその不整合により自らが失敗作であることを宣言し続けることになる。CommonMarkとはそういう失敗した言語と解析器なのである。このようにCommonMarkは新構文だけまたは解析器だけ文脈依存に変更しても理論的齟齬が解析結果と使用感の不自然さと違和感に明白に表れるためCommonMarkが失敗した言語である事実は到底隠し切れるものではない。Markdownはもはや負債以外の何物でもないCommonMarkの異常な解析規則を捨てて素直な文脈依存構文言語として新しい仕様を作り直すのが賢明である。 文脈依存言語を再帰的バックトラックなしで解析可能な方法は2つある。一つは解釈を予言的に決定する方法、もう一つは予備的または中間的その他事前の解析結果に対する解釈を事後に決定する方法である。前者は構文を峻別するための制約が強く後者は共通構造の適切な設計が必要でありいずれも再帰的バックトラックを防ぐために未終端の構文も受理する必要がある。しかし予言的解析は類似の異文脈構文へのバックトラックが不可能になるため共通構造についての事前解析結果のような追加情報を利用できるのでなければ類似の異文脈構文の定義が不可能になる。また共通構造をバックトラックなしで解析するにはそのための言語設計が必要であることに変わりなく任意の文字列を使用可能である必要があるURL、コード、数式などに含まれる任意の文字列が他の構文と文脈で解釈される際に共通構造を破壊するためこのような文字列を構造的に決定的に解釈する基本構造(バックトラック可能だが入力に対する解析結果がすべての文脈で構造的に共通すなわち決定的でなければならない。構文が解析されない場合も構文全体が包含されれば問題ない)を共通構造に定義しなければ構造的共通化は不可能であり分離構造は終端不要な開放可能構文としての予言的構文でなければバックトラックが不可避となる。共通構造の事前解析は一見すると最悪計算量を2nに削減できるように見えるが実際には共通構造をバックトラックなしで解析することが元の言語より容易にはなっても依然として難しくバックトラックなしで解析できたとしてもすべての解析ひいては平均計算量が+1nされるため平均的にはむしろ計算量を悪化させる方法であり仮に最悪計算量32nを事前解析により2nに抑えられたとしても平均計算量が1nならば平均計算量が2nに倍加し実行性能が半減および実行コストが倍加するため明らかに事前解析を行うべきでない。実用的なアルゴリズムの計算量において重要なのは最悪計算量がO(n^3)相当以下の実用的な計算量であるかと平均計算量でありその他は重要ではない。メモ化が空間計算量を代償に悪化させる最悪時間計算量線形化手法であるのに対して事前解析は平均時間計算量を代償に悪化させる最悪時間計算量線形化手法でありマーキング法は何も代償に悪化させない最悪時間計算量線形化手法である(無論ゼロコストではないが解析の他の部分やASTに要するコストより小さいため無視できる。空間計算量は実際にはASTにより容易に数倍になりメモリ使用量は入力サイズと並列数に制約されるため空間計算量自体はさほど重要ではなく空間計算量を増加させる処理により生じる時間オーバーヘッドのほうが本質的に重要となる。メモ化が常時記録かつ実データ記録ゆえデータ数もデータサイズも大きいのに対してマーキング法は失敗時記録かつフラグのみ記録ゆえデータ数もデータサイズも小さいことでオーバーヘッドが最小化されバックトラック率の低い入力が大多数を占める場合の平均実行速度が高速化される。平均性能すなわち重要指標が向上するならばその他の指標は許容範囲内で悪化させることができ不要な指標値を必要な指標値に変換できるならばそうしなければならない)。なおマーキング法を使用するSecuremarkは本来の構文解析と共通構造解析を統合し同時解析することで計算量の増加なく共通構造解析を行い共通構造を利用して最悪時間計算量を指数計算量から5nへ削減している。 ### 実行性能 構文数と使用記号数が大きく異なるため単純な比較はできないが直接比較してもにブラウザによるHTMLパース時間を含めた速度差はCommonMarkの1/3、CommonMarkの問題の解決を試みたdjotと同等程度でありすでに十分高速である。 ### 標準化 Markdownのように自然言語と自身の文法を分離する汎用構造がないメタ言語は構文を拡張する際に旧構文を破壊する新構文が自然言語の中に潜在せざるをえず後方互換性を保証することが不可能である。 このためCommonMarkは拡張構文を標準化した次期標準仕様との互換性を確保する役には立たずその有用性は構文の拡張を考慮しない範囲での効率的な実装方法の例示およびテストケースの集積による個別実装の支援ならびにその結果としての限定的互換性にとどまる。 さらにCommonMarkは前述の解析時間の制約から拡張性が低く、高度な構文や機能の実装可能性を考慮していないことから拡張仕様において準拠すべき技術的正当性もない。 実際GFMが二種類のフェンスドブロックのセマンティクスを分けずCommonMarkに準拠して単なるエイリアスとして有用な記号を浪費したのは顕著かつ明白な失敗だったと言えよう(Securemarkでは入力文字列の無変換表示(シンタックスハイライト)用と変換表示(拡張構文)用に分かれている)。 よってMarkdownの標準化は後方互換性確保が不可能であることから発展性がなくスナップショット以上の技術的意味を持たない。 MarkdownはGFMのように最初から高機能で完成度の高い拡張不要な独自実装のほうが標準としての互換性を確保でき、構文に曖昧さがない形式言語と異なりまず最小限の標準仕様を策定しのちに拡張していく通常の標準化方法が適さない特殊な言語である。 Markdownに本当に必要な仕様はSecuremarkのクラス化制約のように構文の解釈の一貫性と安定性を保つ仕様、バックトラックを抑制する仕様、拡張を確保する仕様などの抽象的仕様であり拡張すると壊れる拡張不可能な具体的仕様などその場限りの価値しかない。 ### CommonMarkの欠陥 - 構文解析戦略の選択の失敗と最小計算量への固執 - 拡張性の欠如 - 文脈依存構文を追加不可能(要解析戦略変更) - 構文解析の破綻(文脈依存言語の文脈自由言語としての解析を仕様化したことによる破綻) - 二重リンク(`[]()`)の生成 - 画像のalt(`![*a*]()`, `![![a]()]()`)をMarkdownとして解釈 - リンクのURLを効率的に解析不可能 - altはまだしもURLは文脈依存構文としての解析を避けられないため再帰もまた避けられず公式デモページのCommonMarkで`[](`を1万回程度繰り返しただけで解析時間が1秒を超える - この欠陥は入れ子数を制限することで回避可能だがこれはCommonmarkは文脈依存構文全般に入れ子数制限を要することを意味する - CommonMarkは最初のバージョンから数年後にこの欠陥を入れ子数制限により修正しこれにより最悪計算量が当初の想定の1nから32nへと32倍に劇的に悪化したことから文脈自由言語および最小計算量としての設計と開発が破綻し失敗に終わったことが明らかである - GFMも`[0]([1]()(...[33]()...))`で32回の再帰的バックトラックを行い最悪計算量が32nであることが確認できる - これほど計算量が悪ければ適切に設計された文脈依存言語より悪い計算量であり素直に文脈依存言語として作り直したほうが遥かに拡張性と発展性が高く優れている - 計算資源は使うためにあるにもかかわらず言語と一致しない不適切な解析方法を使用してまでこの程度のわずかな計算資源を惜しんで人間に不便と不自由を強いて生産性を下げるのは本末転倒である - 計算機は人間の生産性に奉仕しなければならない - タブまたは4スペース以上で字下げ不可能(要構文削除) - 情報の再利用困難性 - 引用に恒等性がない - 改行に恒等性がない ### CommonMarkの解析規則の問題点 開閉が明示的でない構文は開閉の不明確な記号による再帰的適用を行わず可能な限り早く閉じるよう解析しなければならない。このため終端記号の後ろを見て終端を中止し同じ構文を再帰的に適用してはならない。従って記号内側の非空白要件以外のflanking要件は不要である。 ``` flanking*!?* -> flanking*!?* ``` `**`が`*`に分解されるか一貫性がなく直感的使用が困難。強調を多重化する不適切で不確実な使用方法より開始記号の信頼性を損なわないことのほうが重要であることから分解しないことが優先される。 ``` **a*b* -> **ab ***a*b*c* -> abc ``` 偶奇へ不必要に依存し偶数個の`*`がすべて``に解析されるため``が含まれるか目視で判別不能。 ``` ******a****** -> a ``` ### djotの解析規則の問題点 次の公式声明の通り解析規則が構文ごとに定義されず先に閉じられた構文を優先する異常な解析規則になっている。 構文解析をスタックベースで行うために異常な解析規則に歪んでいる。 ``` Most inline syntax is defined by opening and closing delimiters that surround inline content, defining it as emphasized, or as link text, for example. The basic principle governing “precedence” for inline containers is that the first opener that gets closed takes precedence. Containers can’t overlap, so once an opener gets closed, any potential openers between the opener and the closer get marked as regular text and can no longer open inline syntax. For example, in _This is *regular_ not strong* emphasis ->

    This is *regular not strong* emphasis

    the regular emphasis opened by the first _ gets closed by the second _, at which point the first * is no longer eligible to open strong emphasis. But in *This is _strong* not regular_ emphasis

    This is _strong not regular_ emphasis

    it goes just the opposite way. ``` 構文すなわち文脈を自然に分離して入れ子にできないということはCommonMarkと同じく拡張困難な設計の言語ということである。 このため文脈を区別しない挙動によるバグが発生する。 ``` _[a](file_name) -> [a](filename) []([]()) _[a](file_name) -> ``` すなわち一般的な通常の文法規則に従っておらずCommonMarkと同じく特定のバックトラック回避技術を使用するために設計と文法規則が根本的に歪んでいる。しかも設計と文法を歪めてまでバックトラック排除に固執していながらHTMLや正規表現ではバックトラックが多発しているため設計を歪めてまでバックトラック排除に固執する意味がなくMarkdownの主要構文に限ってバックトラックを完全排除する無意味な自己満足のために異常な解析規則を強いる非常に不自然で歪んだ言語になっている。CommonMarkとdjotはいずれもバックトラックと計算量を中途半端に最小化するという自己満足と技術的手段のために他のすべてを犠牲にしており総じて手段に目的を従わせ歪ませる開発者の人間性と能力の低さが見て取れる。 ### トランスクルージョン 分散的に管理される情報のトランスクルージョンは権利関係の不明瞭さおよびリンク先の消失によりリンク元の情報に欠損が生じるなどの脆さから壊れやすいウェブ上の情報を扱う方法として既存の方法より劣っておりWikipediaのように中央集権的管理を実施できる場合にのみ有用となる。 ### Data URI Data URIは保存および転送容量削減ならびにユーザーおよび管理者双方の集約的管理のためサポートしない。 特に規制および公開レベルの媒体別設定の実現のためテキストとメディアの分離が必須となる。 ### HTML - \: 法的表記を縮小表示すべきでないため削除。 - \: \の代わりに使用されないよう削除。他の構文との相性も悪い。 - \: 同上。 ### _ emphasis 外側非空白要件なしでは非分かち書き言語で使用できず非空白要件ありではオートリンクと単語検索と致命的に相性が悪いため不採用。