ページの中の要素を指定する記法
全てURIで」のURIでも使えるように。ページ名に続いて要素指定。

Wikiの設定/構築に使ったり、クライアントアプリから使ったり、他アプリとの連携用にしたり。

データコンテキストでの呼びだされ時と同じ Edit

使われるコードはデータコンテキストで呼ばれた時と同じもの。
データコンテキストではどのメソッドを呼び出すかが文脈で決まるが、
ログラムコード内では普通にメソッドを指定していい。

セレクター記法 Edit

querySelectorAll風。

旧検索[?]で探す Edit

要素を選択する処理。
要素を選択するには要素のインスタンス名やクラス名で。旧検索は値(内容)で探すもの。データアクセスからは使わない。

下位展開埋め込み解決後に Edit

下位展開の基準から下位ページにアクセス可能に。
埋め込まれた要素にもアクセス可能に。

埋め込み下位展開後でなければアクセス不可能な要素ができてしまうし、閲覧時に見た通りに使えなければ分かりにくい。

見た通りなので下位展開された下位ページの要素にもアクセス可能にしないと。上位に下位が付いてくるので「継承」とは呼ばない。方向が逆。

:Done/下位展開で下位のページ属性は参照できるか
…はページ/属性(へのデータアクセス)なので別領域の話。ページ/内容にある要素にはデータアクセス可能。つまり下位展開分にもデータアクセス可能。

普段通りの挙動 Edit

データアクセスでも他の呼び出し方でも処理は同じ。コードも同じ。
HTMLを要求してもHTMLヘッダーも無い断片が返ってくる。

HTMLヘッダーがいるなら連鎖の始まりにあたるデータコンテキストをそういう指定にして。

URIもコンテキスト Edit

URIのクエリー文字列で指定して呼ぶとき、HTMLとかRSSとかの形式を指定するには基礎となる要素を付け足す。付け足す要素はページ内に存在しなくてもいい。URIだけの即席要素。
URIに書くときはパラメーターの指定がしづらいので、指定できるのはパラメーターを1つしか受けない要素だけ。コンテキストを作るだけの要素なのでURIでしか使い道がない。

指定しなければデフォルトのコンテキストページと同じコンテキストを作る要素。

連鎖はできなくていい Edit

URIでは要素のパラメーターを書きにくいので、(URI上では)複数の要素を組み合わせられなくてもいい。
組み合わせるならページに書いて。それを呼び出すようにして。

記法の代わりになるもの Edit

セレクター記法の代わりに要素セットやページセットも渡せるように各要素が考慮する。
別にパラメーター名を変えてもいいし、ひとつのパラメーターを複数のに対応させてもいい。

:Done/セットの扱い

インポートと近い Edit

JSONインポートと実装が一部共通。