ページ/型について再考 † 
- 今のところ属性/継承はページで行なっている。継承付きでページ/属性を参照するAPIがある。
- 記法でなくHTMLを書くページは…
ページごと要素に書くのでも可。入力は通常通り。入力をどう出力するかだけの問題。→ でも要素でなくページ/型で実現。 - 全ての行がリストになったり、LTSVを書くためのページは…エディターを変える必要がある。あとはHTMLと同じ。→ これもページ/型で実現。
ページ/型は添付ファイルの型 †
ページ/内容も添付と同じ扱いにするので、「ページ/要素」というページ/型にして添付ファイル扱い。
ページ/型はクラスで表現。「ページ/要素」を含むMIMEタイプのうち、いずれかを指定。
CSVなどを入力するときはMIMEタイプで指定（記法で書いたテーブルをCSVで出力するならページ型は「ページ/要素」を示すMIMEタイプ、出力をデータコンテキスト型text/csvで行なう）。HTML書き込みのときもMIMEで指定。Markdownはページ/要素を表す記法なので、「ページ/要素」の一種とする。
「ページ/要素」も独自のMIMEタイプにしてしまうのがいい。application/prs.X.document とか application/x-X-document とか。
ページは属性領域の集まり。そのひとつがページ/内容で、ページ/型名が書かれていて、型名を冠したクラスに型別の操作方法が定義されている。独自オブジェクトを操作するクラスは1つ。それが今のPageクラス（の一部）。
要素やPNGはいいけどHTMLはだめという編集権限はどう設定するのか？→「ページ/型:HTMLを投稿できる」という権限/鍵と錠をファイルアップロードのユースケースで判定。
錠の無い権限にする？
→どこかのページにだけこの錠を与えておけば、これを継承した下位ページだけでHTMLを受け入れるという仕様にしたい。権限/錠は「鍵を要求する」のと、「鍵があれば許可する」という意味。
閲覧権限も別に設定できたほうが一貫性が保てていい。「ページ/型:HTMLを見られる」という錠と鍵が揃うとページ/型:HTMLのときでもページを閲覧できる。
「（このページが）ページ/型:HTMLのときページを閲覧できる」といった表記のほうがいい。
ページの内部 †
それぞれのページは要素のコンポジション。
ドキュメントとスレッドのページ/型は「ページ/要素」ほか添付ファイル次第の型にもなる。
属性／裏／権限領域のページ/型は「ページ/要素」だけで参照時に属性/継承などの特殊処理。それとも独自型で別クラスにする？
スレッドは1件1件がドキュメントと同じ型 †
ドキュメントはスレッド投稿の1件に相当。それぞれページ/型を持つ。
多くの場合、ドキュメントのページ/型は「ページ/要素」。スレッドのページ/型は「text/plain」。
スレッド1件ごとのページ名が、その位置を表す。対象ページ名と、ツリー上の親ノードのIDを合わせたもの。
スレッド投稿1件をページ化すると、権限が適正になる。ドキュメントについての書き込み権限と、そのドキュメントの下位にページ作成権限があれば可能。リンク構造も正確になり、関連ページが的確になる。
属性領域はただのページ †
属性領域もページ。ページには属性領域があるけど「属性領域の属性領域」は作らない。
ページと属性領域は同じ名前を持つだけで、定義上は無関係。クラス定義でもページの参照と同じAPIで属性領域を参照。
属性領域の特殊な参照方法（属性/継承してから参照）は参照する側で行なう。属性領域を参照するときは必ず継承処理も行なう…というのをカプセル化したクラスをコントロール層に用意。ページクラスは使い勝手の良さやプログラミングのしやすさとは無縁にしておく。
ページ/属性を何かと統一できない？ †
特殊な点 †
属性/継承処理が特殊。
これをどこで定義して、何をトリガーにするのか？
→属性の参照時。
属性を参照する側が処理するのか／参照される側が処理するのか？
→参照される側。参照される側は自身が属性だと自覚していなければならない。
属性の参照方法は特殊なもの？
→属性であることくらいは意識しないと。
ページ/内部名と属性領域名（裏／権限などもここで指定）とページ/要素名（複数）を指定すれば、継承済みのすぐに使える値が（Dictionary型で）手に入るように。
ページ/要素を指定しなければ全ての属性値が手に入って、受け取った側でいろいろ探せるように。
継承があると（継承ルールの「連結」により）値が必ずコレクションになってしまう。データ型が通常のデータアクセスとは変わってしまうので、参照方法もデータアクセスとは違うものにしなければならない。その代わりデータアクセスとは違う形式の値を返していい。
データコンテキストの指定で属性/継承すれば分かりやすい？ †
継承ルールの「連結」を排除すればデータアクセスと統一できる。
属性であることや継承などを気にするのは、参照される側だけでいい。隠蔽。
直近の親が複数あるので連結が必要になっている→その複数の値は自身の値が無いときだけ。
→「連結」の排除は不可能。必要な場合がある。
データコンテキストの指定で（参照する側で）継承付きの参照方法を使う？「属性」コンテキスト。APIとしては使いにくくなるけど、全てデータコンテキストでというのは分かりやすい。
属性領域は他のデータコンテキストで読めてもいいので、その仕様と統一。
データコンテキストでの指定だと、Xの外からも継承付き参照ができる！！
→コンテキスト「属性」でデータアクセスすると、継承済みの属性値が手に入るように。継承ルールの「連結」があるので値はいずれもコレクション。この点が他のコンテキストと異なる。
他に「権限」というのも。
ページ/裏の場合は「属性」にする。でも継承はない。（将来、継承ありになってもそのままでいい）
「属性」コンテキストでは形式が分からない。他は「HTML」や「JSON」なので「属性」ではなく…？（でも継承付きであることが分からなければならない）
→データコンテキストは形式か型。「属性」ではなく「継承ありのDictionary」であるべき。
記法定義 †
記法はページ/要素と別。どんな記法がどの要素になるのかは変更可能。
記法定義をどこに書くか †
（Xにおいて）記法が存在するのはページ/型がページ/要素になっているページ。
記法系はデータコンテキスト！ページ/型がNotationTextで、コンテキストがWikiCreoleなら===が見出しになる。それがMarkdownコンテキストでは###に変化。要素クラスで記法定義をしなくていい。記法→要素のときは「データコンテキスト」と呼んでいない？→パース？→記法はデータコンテキストと別。記法はデータコンテキスト「NotationText」のときの更に細かい型。
例えば日付記法。WikiCreoleでもMarkdownでもリスト記法が同じであるように、日付記法も同じ。
WikiCreoleでの日付記法と、Markdownでの日付記法で定義が重複する？定義は記法系別か要素別か？→記法別。1つの記号が記法によって異なる要素になり得るので。同じ定義が複数の記法にあっていい。
（プラグイン要素の）記法定義は要素別に管理者設定。要素はインストール／アンインストールするので。記法別だと要素を導入するとき記法クラスを書き換えなければならない。要素によっては対応できない記法があるので、「記法定義が無ければ汎用記法になる」…といった定義ができるように。
記法――オブジェクト変換は双方向 †
例えば、リスト内の改行は…
オブジェクト→PukiWikiのときにPukiWikiの改行記法に置き換え。
オブジェクト→Markdownのときは改行文字に置き換え。
…なので、記法に依存。
リストの場合なので、要素クラスにも依存。
どの要素が×どの記法になるのか…に依存するということ。
どう定義するか？
→これまで通り、要素にToMarkdown()を定義。要素単位でインストール／アンインストールできるように。
入力…記法→オブジェクトも要素で。これまで通り。
要素を2系統に分ける †
- DOMにある要素
- DOMに無い要素
記法はカスタマイズ可能に。
既存記法の無効化はどう行なうか？
→要素クラス別のページで正規表現を再定義。シンタックスシュガーもここで追加できる。ビルトインの記法を削除して、プラグインの要素の記法にするとかも。
カスタマイズを2系統に分けて考えると…
DOMにある要素の場合はインストールすることはない。記法系ごとに定義してチートシート風にできる。要素ごとでなくていい。
それ以外はインストール／アンインストールするけど記法系に依存せず常に同じ記法になるはず。インストールしやすくするため要素ごとに記法定義するけど、記法は汎用記法1つでいい。設定で付け足すことができる。
記法系は後からでも増やせる。DOMにある要素の記法を増やせば足りるので可能。
それと…
記法→オブジェクトを定義するのは、オブジェクト→記法と同じクラスで。
記法系ごとのクラスは必要 †
記法→オブジェクトでは要素クラスの優先順位と、要素クラス間の上下関係を規定する記法系クラス（例えばMarkdownを表すクラス）が要る。「この要素の下にあの要素は作れない」など。
記法系クラスは…
ビルトイン要素ではMarkdownなどといった記法系を表すクラス。
プラグイン要素では今のTokenize()をするクラス。
記法系を表すクラスは例えば…見出しクラスからRegexを得て、引用よりも後に評価するとか、マッチした部分を見出しのコンストラクターに渡し、その際に下位要素になり得る要素のクラス名を全て指定する…といったことをするクラス。
記法定義とデータコンテキストとページ/型 †
- データコンテキストが有効なのは、ページ/型が「ページ/要素」のとき。
- ページ/型がCSVならどんなコンテキストでもCSVでしか出力されない。
CSV変換可能なページ/要素（例えば表）を使って書かれているのではなく、CSVファイルをアップロードした場合。
これをページ/要素の表に置き換えるような機能はあってもいいけど後付けで。→ :i/CSVファイルをページ要素のCSVに変換
ページ/要素が対応すべきデータコンテキスト †
- プラグイン要素が対応すべきデータコンテキストは"NotationText"ひとつ。どんなコンテキストでも汎用記法（または日付のように独自形式）で返す。
- ビルトイン要素は各種記法系のほか、HTMLとかJSONとか。データコンテキストにしっかり対応。
どの記法系で出力するときもデータコンテキストでは同じ"NotationText"という型。別のクエリーパラメーターで何記法かを指示される。どの記法でも同じ表記になるプラグイン要素にとっては、そのクエリーパラメーターを無視して"NotationText"にさえ対応すればいいので好都合。
ほか †
CSVコンテキストでは最上位のみフィールド生成 †
データコンテキストは下位要素に引き継がれるので、下位要素もフィールドを生成しそうになる。でもCSVはネストしないもの。
リクエストを直接受けた要素（クエリーパラメーターで指定された要素）では下位要素の生成したCSVフィールドを平坦化（""でくくるだけ）。
他のコンテキストでも同様に。