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

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

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

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

jQuery風セレクター † Edit

またはCSS風セレクターで、要素を指定。

タグ名にあたるのが要素のクラス名。
継承したクラス名にあたるのが要素インスタンスが持つ"dotAnnotations"属性。ノートアプリの「タグ」にあたるもの。でもこの言葉はもうマークアップタグとして使ってしまっているので。
:nth…とか:firstとか:evenみたいな疑似セレクターにあたるものは必要なものを似せて実装。

XPath風ではない † Edit

"XPath風"は要らない。構造を無視したアクセスがしたい。

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

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

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

普段通りの挙動 † Edit

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

HTMLヘッダーがいるなら最初のデータコンテキストを指定して。

URIもコンテキスト † Edit

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

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

連鎖はできなくていい † Edit

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