ページは利用者が書くもの。データアクセスでは更新できない。
ページは利用者が書くものだけど、ページ/要素の配置や削除をしたり、ページ/要素のパラメーター（汎用記法のパラメーターでもある）を更新したい。
→ 編集処理（型はユースケース）のパラメーターにページだけでなくページ/要素を指定できればいい。あとは編集処理に任せる。
ページ/裏にあるページ/要素なら更新してもいい。† :i/システムが書くページ裏[?]
それ以外のページは記法以外の形式では更新できない？
通常のページ書換えは総入れ替え † 
新しいページインスタンスになる。
JSONで更新できるか †
JSON送信→各要素クラスのコンストラクターに渡す。コンストラクターでValidate.
セレクターで指定された部分を置き換える機能も。ページ本文の全体を置き換えるには%ルート要素を%ページ内のすべての要素を置き換える。要素は個別に操作しやすいようにするため、ツリー構造ではなく独立させるので。
クライアント→サービスは要素の置き換え（投稿）。の他、要素への指示（データアクセス）もある。データアクセスでも更新があるかも知れない。受けた要素次第
要素を同じ型で置き換える以外に、削除や追加も。
対象要素自身に指示を出す †
置き換え・削除・追加は要素の所有者（親要素）に影響する操作だけど、それだと指定しづらいので削除したい要素だけに指示して行ないたい。
この指示はすべての要素が受け付けられるようにする。
要素に絶対パスを与える †
親要素が必要な相対パスでなく、ページ内の位置で示す絶対パスで要素を指定。対象要素を参照・操作するだけでその要素の移動ができる。ツリー構造をたどらなくていい。
追加は要素にパスを与えるだけ。重複があっても有効。順序不定になるだけ。
削除はパスを無効な値にするだけ。
置き換えは追加と削除。
移動はパスを変更するだけ。
位置を示すのに連番を使うと追加がやりにくい？
JSONもNotationTextも同じ用途 †
どちらもページ内要素の置き換えに使うもの。
要素への指示（データアクセス）はリクエスト付属のクエリーパラメーターで。クエリーに書かれた要素がクエリー全体を参照して解釈できるものだけ利用する。フレームワーク/WikiEngineは要素を呼ぶだけ。どんな名前でどんな書式のパラメーターが必要かは要素次第。その中でNotationTextやJSONが使われることはある。ページ投稿・編集もその内の1つで、投稿フォーム要素にNotationTextを渡して行なうもの。