1. ページ/型について再考
    1. ページ/型は添付ファイルのもの
  2. スレッドは1件1件がドキュメントと同じ型
  3. ページ/属性を何かと統一できない？
    1. 特殊な点
    2. データコンテキストの指定で属性/継承すれば分かりやすい？
  4. 記法
    1. 記法定義をどこに書くか
    2. 対応すべきデータコンテキスト
    3. CSVコンテキストでは最上位のみフィールド生成

ページ/型について再考 † Edit

ページ/型は添付ファイルのもの † Edit

ページ/内容も添付と同じ扱いにするので、ページ/型を「ページ/要素」にして添付ファイル扱い。
ページ/型はクラスで表現。「ページ/要素」かMIMEタイプのいずれかを指定。
CSVなどを入力するときはMIMEタイプで指定（記法で書いたテーブルをCSVで出力するなら型は「ページ/要素」、出力をデータコンテキスト型「CSV」で行なう）。HTML書き込みのときもMIMEで指定。Markdownはページ/要素を表す記法なのでMIMEタイプではなく「ページ/要素」。

「ページ/要素」も独自のMIMEタイプにしてしまうのがいい。application/prs.X.document とか application/x-X.document とか。

ページの本体は属性領域。そこにページ/型名が書かれていて、型名を冠したクラスに型別の操作方法が定義されている。独自オブジェクトを操作するクラスは1つ。それが今のPageクラス（の一部）。

要素やPNGはいいけどHTMLはだめという編集権限はどう設定するのか？→「ページ/型:HTMLを投稿できる」という権限/鍵をファイルアップロードのユースケースで判定。錠の無い権限？→どこかのページにだけこの錠を与えておけば、これを継承した下位ページだけでHTMLを受け入れるという仕様にしたい。権限/錠は「鍵を要求する」のと、「鍵があれば許可する」という意味。
閲覧権限も別に設定できたほうが一貫性が保てていい。「ページ/型:HTMLを見られる」という錠と鍵が揃うとページ/型:HTMLのときでもページを閲覧できる。
「ページ/型:HTMLのときページを閲覧できる」？？

スレッドは1件1件がドキュメントと同じ型 † Edit

ドキュメントはスレッド投稿の1件と同じ型。それぞれ内部にページ/型を持つ。
多くの場合、ドキュメントのページ/型は「ページ/要素」。スレッドのページ/型は「text/plain」。

→:スレッドモードはドキュメントモード

ページ/属性を何かと統一できない？ † Edit

特殊な点 † Edit

属性/継承処理が特殊。

これをどこで定義して、何をトリガーにするのか？
→属性の参照時。

属性を参照する側が処理するのか／参照される側が処理するのか？
→参照される側。参照される側は自身が属性だと自覚していなければならない。

属性の参照方法は特殊なもの？
→属性であることくらいは意識しないと。

ページ/内部名と属性領域名（裏／権限などもここで指定）とページ/要素名（複数）を指定すれば、継承済みのすぐに使える値が（Dictionaryで）手に入るように。
ページ/要素を指定しなければ全ての属性値が手に入って、受け取った側でいろいろ探せるように。

継承があると（継承ルールの「連結」により）値が必ずコレクションになってしまう。データ型が通常のデータアクセスとは変わってしまうので、参照方法もデータアクセスとは違うものにしなければならない。その代わりデータアクセスとは違う形式の値を返していい。

データコンテキストの指定で属性/継承すれば分かりやすい？ † Edit

継承ルールの「連結」を排除すればデータアクセスと統一できる。
属性であることや継承などを気にするのは、参照される側だけでいい。隠蔽。
直近の親が複数あるので連結が必要になっている→その複数の値は自身の値が無いときだけ。
→「連結」の排除は不可能。必要な場合がある。

データコンテキストの指定で（参照する側で）継承付きの参照方法を使う？「属性」コンテキスト。APIとしては使いにくくなるけど、全てデータコンテキストでというのは分かりやすい。
属性領域は他のデータコンテキストで読めてもいいので、その仕様と統一。
データコンテキストでの指定だと、Xの外からも継承付き参照ができる！！
→コンテキスト「属性」でデータアクセスすると、継承済みの属性値が手に入るように。継承ルールの「連結」があるので値はいずれもコレクション。この点が他のコンテキストと異なる。
他に「権限」というのも。
ページ/裏の場合は「属性」にする。でも継承はない。（将来、継承ありになってもそのままでいい）

「属性」コンテキストでは形式が分からない。他は「HTML」や「JSON」なので「属性」ではなく…？（でも継承付きであることが分からなければならない）
→データコンテキストは形式。「属性」ではなく「Dictionary」であるべき。

データコンテキストと属性/継承は合わない。

記法 † Edit

記法定義をどこに書くか † Edit

（Xにおいて）記法が存在するのはページ/型がページ/要素の場合。

記法系はデータコンテキスト！！ページ/型がNotationTextで、コンテキストがWikiCreoleなら===が見出しになる。それがMarkdownコンテキストでは###に変化。要素クラスで記法定義をしなくていい。記法→要素のときは「データコンテキスト」と呼んでいない？→パース？→記法はデータコンテキストと別。記法はデータコンテキスト「NotationText」のときの更に細かい型。

例えば日付記法。WikiCreoleでもMarkdownでもリスト記法が同じであるように、日付記法も同じ。
WikiCreoleでの日付記法と、Markdownでの日付記法で定義が重複する？定義は記法系別か要素別か？→記法別。1つの記号が記法によって異なる要素になり得るので。同じ定義が複数の記法にあっていい。

（プラグイン要素の）記法定義は要素別に。要素はインストール／アンインストールするので。記法別だと要素の導入で記法クラスを書き換えなければならない。要素によっては対応できない記法があるので「その他の記法」なら汎用記法になる…といったことができるように。

  • 記法　→　要素クラス名とそのコンストラクターに渡すパラメーター
  • 要素インスタンス　→　パラメーター埋め込み済みテキスト
    …ができれば記法変換はできる。

リスト内の改行は…
オブジェクト→PukiWikiのときにPukiWikiの改行記法に置き換え。
オブジェクト→Markdownのときは改行文字に置き換え。
…なので、記法に依存。

リストの場合なので、要素クラスにも依存。

どの要素が×どの記法になるのか…に依存するということ。
どう定義するか？
→これまで通り、要素にToMarkdown()を定義。要素単位でインストール／アンインストールできるように。
入力…記法→オブジェクトも要素で。これまで通り。

要素の種類

  • DOMにある要素
  • DOMに無い要素
    • 日付とか
    • パラメーターが豊富
    • 記法系に左右されない
    • 汎用記法でも書く
    • 簡易マークアップ記法にない。合わせて使用しても競合せずに使用可能。
    • プラグインなので、要素ごと追加／削除したい。

記法はカスタマイズ可能に。
既存記法の無効化はどう行なうか？
→要素クラス別のページで正規表現を再定義。シンタックスシュガーもここで追加できる。ビルトインの記法を削除して、プラグインの要素の記法にするとかも。

カスタマイズを2系統に分けて考えると…
DOMにある要素の場合はインストールすることはない。記法ごとに定義してチートシート風にできる。要素ごとでなくていい。
それ以外はインストール／アンインストールするけど記法系に依存せず常に同じ記法になるはず。インストールしやすくするため要素ごとに記法定義するけど、記法は1つでいい。
記法系は後からでも増やせる。DOMにある要素の記法を増やせば足りるので可能。

それと…
記法→オブジェクトを定義するのはオブジェクト→記法と同じクラスで。

対応すべきデータコンテキスト † Edit

プラグイン要素が対応すべきデータコンテキストは…記法系は1つ、汎用記法だけ。ビルトイン要素は…HTMLとかJSONとか。データコンテキストにしっかり対応。

どの記法系で出力するときもデータコンテキストでは同じ"NotationText"という型。別のクエリーパラメーターで何記法かを指示される。どの記法でも同じ表記になるプラグイン要素にとっては「別のクエリーパラメーター」を無視すればいいので好都合。

CSVコンテキストでは最上位のみフィールド生成 † Edit

コンテキストは下位要素に引き継がれるので、下位要素もフィールドを生成しそうになる。でもCSVはネストしないもの。
リクエストを直接受けた要素（クエリーパラメーターで指定された要素）では下位要素の生成したフィールドを平坦化（""でくくるだけ）。

他の型でも同様に。