- 追加された行はこの色です。
- 削除された行はこの色です。
RIGHT:[[:t/型]] [[:t/スレッド]] [[:t/データコンテキスト]] [[:t/記法]] [[:t/実装]]
#contents
**ページ/型について再考 [#jece6f69]
- 今のところ属性/継承はページで行なっている。継承付きでページ/属性を参照するAPIがある。
- ページは複数ページのコンポジション。それぞれは要素のコンポジション。
-- ドキュメント／スレッド／属性／裏／権限…これらのページ/型は？これら自体は型ではないはず。→ドキュメントとスレッドは「ページ/要素」ほか添付ファイル次第。属性以下は「ページ/要素」で参照時に特殊処理。%%それとも独自型で別クラスにする？%%
- HTMLを書くページは…ページごと要素でも可。入力は通常通り。テキストをどう出力するかだけの問題。→でもページ/型で。
- 全ての行がリストになったり、LTSVを書くためのページは…エディターが変わるかも知れない。あとはHTMLと同じこと。→ページ/型で。
***ページ/型は添付ファイルのもの [#o051e5a4]
ページ/内容も添付と同じ扱いにするので、ページ/型を「ページ/要素」にして添付ファイル扱い。
ページ/型はクラスで表現。「ページ/要素」か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件がドキュメントと同じ型 [#kf220197]
ドキュメントはスレッド投稿の1件と同じ型。それぞれ内部にページ/型を持つ。
多くの場合、ドキュメントのページ/型は「ページ/要素」。スレッドのページ/型は「text/plain」。
[[→:スレッドモードはドキュメントモード]]
**ページ/属性を何かと統一できない？ [#seb157ad]
***特殊な点 [#lc2f31f6]
属性/継承処理が特殊。
これをどこで定義して、何をトリガーにするのか？
→属性の参照時。
属性を参照する側が処理するのか／参照される側が処理するのか？
→参照される側。参照される側は自身が属性だと自覚していなければならない。
属性の参照方法は特殊なもの？
→属性であることくらいは意識しないと。
ページ/内部名と属性領域名（裏／権限などもここで指定）とページ/要素名（複数）を指定すれば、継承済みのすぐに使える値が（Dictionaryで）手に入るように。
ページ/要素を指定しなければ全ての属性値が手に入って、受け取った側でいろいろ探せるように。
継承があると（継承ルールの「連結」により）値が必ずコレクションになってしまう。データ型が通常のデータアクセスとは変わってしまうので、参照方法もデータアクセスとは違うものにしなければならない。その代わりデータアクセスとは違う形式の値を返していい。
***データコンテキストの指定で属性/継承すれば分かりやすい？ [#i83582ed]
継承ルールの「連結」を排除すればデータアクセスと統一できる。
属性であることや継承などを気にするのは、参照される側だけでいい。隠蔽。
直近の親が複数あるので連結が必要になっている→その複数の値は自身の値が無いときだけ。
→「連結」の排除は不可能。必要な場合がある。
データコンテキストの指定で（参照する側で）継承付きの参照方法を使う？「属性」コンテキスト。APIとしては使いにくくなるけど、全てデータコンテキストでというのは分かりやすい。
属性領域は他のデータコンテキストで読めてもいいので、その仕様と統一。
データコンテキストでの指定だと、Xの外からも継承付き参照ができる！！
→コンテキスト「属性」でデータアクセスすると、継承済みの属性値が手に入るように。継承ルールの「連結」があるので値はいずれもコレクション。この点が他のコンテキストと異なる。
他に「権限」というのも。
ページ/裏の場合は「属性」にする。でも継承はない。（将来、継承ありになってもそのままでいい）
「属性」コンテキストでは形式が分からない。他は「HTML」や「JSON」なので「属性」ではなく…？（でも継承付きであることが分からなければならない）
→データコンテキストは形式。「属性」ではなく「Dictionary」であるべき。
データコンテキストと属性/継承は合わない。
**記法定義 [#y6c3bf94]
記法はページ/要素と別。どんな記法がどの要素になるのかは変更可能。
***記法定義をどこに書くか [#g389c5a6]
（Xにおいて）記法が存在するのはページ/型がページ/要素の場合。
%%記法系はデータコンテキスト！！ページ/型がNotationTextで、コンテキストがWikiCreoleなら===が見出しになる。それがMarkdownコンテキストでは###に変化。要素クラスで記法定義をしなくていい。記法→要素のときは「データコンテキスト」と呼んでいない？→パース？%%→記法はデータコンテキストと別。記法はデータコンテキスト「NotationText」のときの更に細かい型。
%%例えば日付記法。WikiCreoleでもMarkdownでもリスト記法が同じであるように、日付記法も同じ。%%
%%WikiCreoleでの日付記法と、Markdownでの日付記法で定義が重複する？定義は記法系別か要素別か？→記法別。1つの記号が記法によって異なる要素になり得るので。同じ定義が複数の記法にあっていい。%%
（プラグイン要素の）記法定義は要素別に。要素はインストール／アンインストールするので。記法別だと要素の導入で記法クラスを書き換えなければならない。要素によっては対応できない記法があるので「その他の記法」なら汎用記法になる…といったことができるように。
（プラグイン要素の）記法定義は要素別に。要素はインストール／アンインストールするので。記法別だと要素の導入で記法クラスを書き換えなければならない。要素によっては対応できない記法があるので「その他の記法」なら汎用記法になる…といった定義ができるように。
--------------------------------------------------
***記法定義は双方向 [#c25108d0]
- 記法 → 要素クラス名とそのコンストラクターに渡すパラメーター
- 要素インスタンス → パラメーター埋め込み済みテキスト
…ができれば記法変換はできる。
リスト内の改行は…
オブジェクト→PukiWikiのときにPukiWikiの改行記法に置き換え。
オブジェクト→Markdownのときは改行文字に置き換え。
…なので、記法に依存。
リストの場合なので、要素クラスにも依存。
どの要素が×どの記法になるのか…に依存するということ。
どう定義するか？
%%→これまで通り、要素にToMarkdown()を定義。要素単位でインストール／アンインストールできるように。%%
%%入力…記法→オブジェクトも要素で。これまで通り。%%
要素の種類
***要素を2系統に分ける [#je7681db]
- DOMにある要素
-- 見出しとか
-- パラメーターもDOM要素
-- ''簡易マークアップ記法にあるもの''
-- 汎用記法ではあまり書かない
-- ''ビルトイン''
- DOMに無い要素
-- 日付とか
-- パラメーターが豊富
-- ''記法系に左右されない''
-- 汎用記法でも書く
-- 簡易マークアップ記法にない。合わせて使用しても競合せずに使用可能。
-- ''プラグインなので、要素ごと追加／削除したい。''
記法はカスタマイズ可能に。
既存記法の無効化はどう行なうか？
→要素クラス別のページで正規表現を再定義。シンタックスシュガーもここで追加できる。ビルトインの記法を削除して、プラグインの要素の記法にするとかも。
カスタマイズを2系統に分けて考えると…
DOMにある要素の場合はインストールすることはない。記法ごとに定義してチートシート風にできる。要素ごとでなくていい。
それ以外はインストール／アンインストールするけど記法系に依存せず常に同じ記法になるはず。インストールしやすくするため要素ごとに記法定義するけど、記法は1つでいい。
記法系は後からでも増やせる。DOMにある要素の記法を増やせば足りるので可能。
それと…
記法→オブジェクトを定義するのはオブジェクト→記法と同じクラスで。
**記法定義とデータコンテキスト [#xd6ed8f3]
***ページ/要素が対応すべきデータコンテキスト [#g9947bb5]
プラグイン要素が対応すべきデータコンテキストは1つ。どんなコンテキストでも汎用記法（または日付のように独自形式）で返す。
ビルトイン要素は各種記法系のほか、HTMLとかJSONとか。データコンテキストにしっかり対応。
- プラグイン要素が対応すべきデータコンテキストは1つ。どんなコンテキストでも汎用記法（または日付のように独自形式）で返す。
- ビルトイン要素は各種記法系のほか、HTMLとかJSONとか。データコンテキストにしっかり対応。
どの記法系（MarkdownやWikiCreoleやPukiWIkiSyntaxやMediaWikiSyntax）で出力するときもデータコンテキストでは同じ"NotationText"という型。別のクエリーパラメーターで何記法かを指示される。どの記法でも同じ表記になるプラグイン要素にとっては「別のクエリーパラメーター」を無視すればいいので好都合。
***CSVコンテキストでは最上位のみフィールド生成 [#vd53563f]
コンテキストは下位要素に引き継がれるので、下位要素もフィールドを生成しそうになる。でもCSVはネストしないもの。
リクエストを直接受けた要素（クエリーパラメーターで指定された要素）では下位要素の生成したフィールドを平坦化（""でくくるだけ）。
他の型でも同様に。
