ページの中の要素を指定する記法。
「全てURIで」のURIでも使えるように。ページ名に続いて要素指定。
ページの中の要素を呼ぶ仕組み。
「全てURIで」のURIでも使えるようにする。
通常のリクエストではページ名を指定するけど、さらに要素指定と型指定もするのがデータアクセス。
Wikiの設定／構築に使ったり、クライアントアプリから使ったり、他アプリとの連携用にしたり。
MediaWikiでのapi.php(prettified)のようなもの。でもMediaWikiのはページ/本文は投稿されたままのテキスト(WikiText)。Xではページ/本文内の表やリストをデータ構造にしたい。
APIとしても使える。MediaWikiでのapi.php(prettified)のようなもの。でもMediaWikiのはページ/本文は投稿されたままのテキスト(WikiText)。Xではページ/本文内の表やリストをデータ構造にしたい。
- -
データコンテキストでの呼びだされ時と同じ † 
使われるコードはデータコンテキストで呼ばれた時と同じもの。
データコンテキストではどのメソッドを呼び出すかが文脈で決まるが、
プログラムコード内では普通にメソッドを指定していい。
データアクセス †
セレクター記法 †
CSS Selector風。querySelectorAllで指定する書式。
XPath風(document.evaluate風)も"/"区切りのURIやページ名とひと続きになっていい。(ページ名区切りは変更可能だけど)
旧検索[?]で探す †
要素を選択するには要素のインスタンス名やクラス名で。旧検索は値（内容）で探すもの。データアクセスからは使わない。
下位展開／埋め込み解決後に †
埋め込まれた要素にもアクセス可能に。
埋め込み
:t/データアクセスより †
:Done/下位展開で下位のページ属性は参照できるか
…はページ/属性（へのデータアクセス）なので別領域の話。ページ/内容にある要素にはデータアクセス可能。
下位展開ではページをまとめないので、単一ページの場合と同じ。
普段通りの挙動 †
データアクセスでも他の呼び出し方でも処理は同じ。コードも同じ。
HTMLを要求してもHTMLヘッダーも無い断片が返ってくる。
未分類 †
HTMLヘッダーがいるなら連鎖の始まりにあたるデータコンテキストをそういう指定にして、各要素がそれに対応するようにして。
URIもコンテキスト †
URIのクエリー文字列にページ/要素を書くと、そこ専用のデータコンテキストで展開される。
URIに書くときはパラメーターの指定がしづらいので、指定できるのはパラメーターを1つしか受けない要素だけ。コンテキストを作るだけの要素なのでURIでしか使い道がない。
あとで:t/データアクセスも追加。
データアクセス/ †
（RSSの場合はビュー別のテンプレートのほうで基礎部分を作ったほうがいい）
指定しなければデフォルトのコンテキスト。ページと同じコンテキストを作る要素。
連鎖はできなくていい †
URIでは要素のパラメーターを書きにくいので、（URI上では）複数の要素を組み合わせられなくてもいい。
組み合わせるならページに書いて。それを呼び出すようにして。
記法の代わりになるもの †
セレクター記法の代わりに要素セットやページセットも渡せるように各要素が考慮する。
型別にパラメーター名を変えてもいいし、ひとつのパラメーターを複数の型に対応させてもいい。
†:Done/セットの扱い
インポートと近い †
JSONインポートと実装が一部共通。
フォーマット †
参考に、MediaWikiの例。
http://www.mediawiki.org/wiki/API:Data_formats#Output