TR X 0048:2001[1]が規定するXSLTは，XPathで定義される式言語を利用して，処理, 条件付き処理及びテキスト生成のための要素の選択を行う。XSLTの処理系の普及と共に, XPathの詳細な理解を求める利用者から, XPathのTR化への要求が高まった。
そこで, 財団法人日本規格協会 情報技術標準化研究センター(INSTAC)の中に設けられた電子出版技術調査研究委員会は, 2001年度の活動としてXPathの調査研究を行い, その重要性を認識して, 標準情報(TR)として公表することが望ましいことを確認した。2002年度から電子出版技術調査研究委員会の作業グループWG1がXPathのTR化の作業を担当し, 2003年1月に標準情報(TR)の原案を完成して経済産業省産業技術環境局に提出した。
訳語選定に際しては，XML関連規定との整合を配慮した。この標準情報(TR)で採用した主な訳語の例を解説表2.1に示す。
| 原語 | 訳語 |
|---|---|
| abbreviated syntax | 短縮構文 |
| closing | 閉じの |
| document order | 文書順 |
| escape | 別扱いする |
| expanded-name | 展開名 |
| forward axis | 順方向軸 |
| fragment identifier | 素片識別子 |
| invalid | 妥当でない |
| left associative | 左結合 |
| lexical structure | 字句構造 |
| literal string | リテラル列 |
| local part | 局所部分 |
| location path | 局所パス |
| location step | 位置ステップ |
| matching | 一致 |
| natural subset | 自然なサブセット |
| non-null | 非ヌル |
| non-terminal | 非終端記号 |
| opening | 開きの |
| operate on | を操作する |
| ordering | 順序付け |
| predicate | 述部 |
| prolog | 前書き |
| prototype | 原型 |
| proximity position | 近接度位置 |
| refine | 洗練する |
| reverse axis | 逆方向軸 |
| reverse document order | 逆文書順 |
| rounding division | 丸め除算 |
| round-to-nearest rule | 直近への丸め規則 |
| string-value | 文字列値 |
| subexpression | 部分式 |
| surface syntax | 表面的な構文 |
| surrogate pair | サロゲートペア |
| syntactic construct | 構文構成子 |
| truncating division | 切捨て除算 |
| variable binding | 変数結合 |
W3Cの規定は, 必ずしもJIS又は標準情報(TR)の様式には整合していないため, 整合化の対応が必要である。しかしTRの読者が原規定を参照する際の便を考慮すると, 章・節構成はなるべく原規定のそれを保存することが望まれる。そこで, 次に示すだけの修正(章・節番号の変更なし)を施して, この標準情報(TR)を構成した。
原規定は, HTMLを用いて記述されている。この標準情報(TR)も原則として, 原規定のタグを保存することにした。
この標準情報(TR)の公表に際して, W3Cから和文及び英文による次の記載を求められている。この記述は原規定にはないため, ここに示して, W3Cの要求に応えることとする。
規定に準拠しているかどうかの基準となる版は, W3Cのサイトにある原規定とする。
この標準情報(TR)は原規定と技術的に同一であることを意図しているが, 翻訳上の誤りはあり得る。
The normative version of the specification is the English version found at the W3C site.
Although this TR is intended to be technically identical to the original, it may contain errors from the translation.
附属書Bにおいて参照されるW3CのXML Infoset については, TR化の計画はないが, このXPathの翻訳を担当したエキスパートグループに含まれるメンバによって行われたXML Information Set (W3C Rec. 2001-10-24)の翻訳を, 次のWebで見ることができる。
http://www.y-adagio.com/public/jttc/infoset/infoset.htm
concat関数(TR本体の4.2を参照。)における記法"*"の意味は, この規定及びErrataにおいて定義されていない。XPathの開発者, 利用者, 既存のXPathの処理系などから調査した結果では, 3番目以降の引数として"文字列型"を0個以上とってよいことを示す。例えば, 五つの文字列を連結したい場合には, concatに五つの文字列型の引数を与えてよいことを示す。最初及び2番目の引数には"*"が付いていないことに注意すること。すなわちconcatは，少なくとも二つの引数をもつ。
原規定の内容を忠実に標準情報(TR)の規定内容とするために, この備考的記述は本文中には含めず, 解説に示すことにした。
XPathに関してはErrataが公表されている。2001年11月までのErrata[2]の翻訳を次に示す。
XMLパス言語 (XPath) 1.0 規定の修正票
2001年11月01日の時点で知られている誤り
A.2 参考文献
XML情報集合(XML Infoset)の参照を次に置き換える。
- XML Infoset
- World Wide Web Consortium. XML Information Set. W3C Recommendation. http://www.w3.org/TR/xml-infoset を参照。
附属書B
附属書Bを次に置き換える。
附属書B XML情報集合との対応付け
XPathデータモデルにおけるノードは，XML情報集合[XML Infoset]によって提供される次の情報項目から導き出すことができる。
B.1 ルートノード
XPathデータモデルのインスタンスは，ただ一つのノードを含み，それは，XML情報集合における一意の文書情報項目に対応する。
ルートノードの子ども は，[children]特性の中に見出される情報項目であって，あらゆる文書型宣言情報項目を省略したものに対応するノードとする。
B.2 要素ノード
要素ノードは，要素情報項目に対応する。
要素ノードの子ども は，[children]特性の中に出現する情報項目に対応するノードとする。この対応は，連続する文字情報項目という子どもが一つのテキストノードに合体されるので，1対1対応ではない。XPathデータモデルは，すべての一般実体が展開されることを要求するので，非展開実体参照情報項目という子どもは，決して存在しない。
要素ノードの属性 は，[attributes]特性の中に出現する属性情報項目に対応するノードとする。
要素ノードの名前空間 は，[in-scope namespaces]特性の中に出現する名前空間情報項目に対応するノードとする。
要素ノードの拡張名 の局所部分は，[local name]特性に対応する。要素ノードの拡張名 の名前空間URIは，[namespace name]特性に対応する。
要素ノードの一意識別子(ID) は，対応する属性が存在する場合には，
IDの[attribute type]特性をもつ[attributes]特性の中の属性情報項目の[normalized value]特性に対応する。そうでない場合には，ヌルとする。
要素ノードの親 は，[parent]特性に対応する。
B.3 属性ノード
属性ノードは，属性情報項目に対応する。名前空間宣言は，属性としてはモデル化されない。
属性ノードの拡張名 の局所部分は，[local name]特性に対応する。属性ノードの拡張名 の名前空間URIは，[namespace name]特性に対応する。
属性ノードの文字列値 は，[normalized value]特性に対応する。
属性ノードの親 は，[owner element]特性に対応する。
B.4 テキストノード
テキストノードは，一つ以上の連続する文字情報項目の列に対応する。
テキストノード文字列値 は，文字情報項目の各々の連結された[character code]特性に対応する。
テキストノード親 は，連続する文字情報項目の任意の一つの[parent]特性に対応する。(連続する文字は，常に，同じ親をもつ。)
B.5 処理命令ノード
処理命令ノードは，処理命令情報項目に対応する。文書型宣言情報項目の子どもとなる処理命令のための処理命令ノードは存在しない。
処理命令ノードの拡張名 の局所部分は，[target]特性に対応する。処理命令ノードの拡張名 の名前空間URIは，ヌルとする。
処理命令ノードの文字列値 は，[content]特性に対応する。
処理命令ノードの親 は，[parent]特性に対応する。
B.7 名前空間ノード
名前空間ノードは，名前空間情報項目に対応する。
名前空間ノードの拡張名 の局所部分は，[prefix]特性に対応する。名前空間ノードの拡張名 の名前空間URIは，ヌルとする。
名前空間ノードの文字列値 は，[namespace name]特性に対応する。
名前空間ノードの親 は，このノードが出現する名前空間の集まりの中の要素ノードとする。
B.8 XML情報集合適合性
この規定は，XML情報集合[XML Infoset]に適合する。次の情報項目は，データモデルのインスタンスを構成するために情報集合生成器によって開示されなければならない。
[children]特性をもつ文書情報項目。
[children]特性，[attributes]特性，[in-scope namespaces]特性，[local name]特性，[namespace name]特性及び[parent]特性をもつ要素情報項目。
[namespace name]特性，[local name]特性，[normalized value]特性，[owner element]特性及び[attribute type]特性をもつ属性情報項目。
[character code]特性及び[parent]特性をもつ文字情報項目。
[target]特性，[content]特性及び[parent]特性をもつ処理命令情報項目。
[content]特性及び[parent]特性をもつ注釈情報項目。
[prefix]特性及び[namespace name]特性をもつ名前空間情報項目。
情報集合生成器によって利用可能なその他の情報項目及び特性は，無視する。
2000年9月29日の時点で知られている誤り
2.2 軸
最後の箇条記号の中の"ancestor軸"を"ancestor-or-self軸"に変更する。
参考 既に反映されている。2.5 短縮構文
4番目の箇条記号のない段落において，
div/descendant-or-self::node()/child::paraは，child::div/descendant-or-self::node()/child::paraとするのがよい。
3.5 数値型(number)
単項のマイナスの意味が規定されていなかった。4番目の段落を次によって置き換える。
2項の-演算子は，減算を実行する。単項の-演算子は，負数を示すことを実行する。-0は，負の0と評価されることに注意すること。
*の意味が，規定されていなかった。次の段落を，div演算子を規定する段落の直前に追加する。
*演算子は，IEEE 754に従って，浮動小数点の乗算を実行する。結果がNaNでない場合，オペランドの両方が同じ符号をもつとき及びそのときに限り，結果が正となることに注意すること。
次の文を，
div演算子を記述する段落に追加する。
結果がNaNでない場合，オペランドの両方が同じ符号をもつとき及びそのときに限り，結果が正となることに注意すること。
3.7 字句構造
次の記述が存在する。
ExprWhitespaceを，ExprTokenの前後のパタン内に自由に追加してもよい。
これを次に置き換える。
ExprWhitespaceを，ExprTokenの前後の式内に自由に追加してもよい。ただし，ExprTokenの中間には追加してはならない。
FunctionNameは接頭辞をもつことができるので，2番目の箇条項目は，NCNameではなくてQNameを参照するように変更するのがよい。
4.2 文字列型関数
次を，
starts-with関数の記述に追加する。
2番目の引数の文字列が空文字列の場合，真を返す。
次を，
contains関数の記述に追加する。
2番目の引数の文字列が空文字列の場合，真を返す。
次を，
substring-before関数の記述に追加する。
2番目の引数の文字列が空文字列の場合，空文字列を返す。
次を，
substring-after関数の記述に追加する。
2番目の引数の文字列が空文字列の場合，最初の引数の文字列を返す。
4.4 数値型関数
次を，
floor関数の記述に追加する。
引数がNaNの場合，NaNを返す。引数が正の無限大の場合，正の無限大を返す。引数が負の無限大の場合，負の無限大を返す。引数が正の0の場合，正の0を返す。引数が負の0の場合，負の0を返す。引数が0よりも大きいが1よりも小さい場合，正の0を返す。
次を，
ceiling関数の記述に追加する。
引数がNaNの場合，NaNを返す。引数が正の無限大の場合，正の無限大を返す。引数が負の無限大の場合，負の無限大を返す。引数が正の0の場合，正の0を返す。引数が負の0の場合，負の0を返す。引数が0よりも小さいが-1よりも大きい場合，負の0を返す。
5. データモデル
相対URIである名前空間の取扱いは，W3C XML Plenaryの決定に従って，実装依存とする。
次の記述がある。
XML文書の中で指定される名前空間URIは，[RFC2396]において定義されるURI参照とすることができる。これは，名前空間URIが素片識別子をもつことができること及び相対的でありうることを意味する。相対URIは，名前空間処理中に絶対URIに解決されることが望ましいので，データモデル内のノードの展開名の名前空間URIは，絶対的とすることが望ましい。
これを次に置き換える。
XML文書の中の名前空間宣言において指定された名前空間名は，[RFC2396]において定義されるとおりのURI参照とする。このことは，それが素片識別子をもつことができ，相対的になることが可能なことを意味する。展開名の名前空間URI構成要素は，その展開名がQNameから展開され，そのQNameの接頭辞が，(素片識別子をもつ又はもたない)相対URIである名前空間名をもつ名前空間宣言によって宣言される場合，実装依存とする。それら展開名の名前空間URI構成要素の値に依存するXPath式は，相互運用可能ではない。
5.4にも同様に，次の記述がある。
名前空間ノードの文字列値は，その名前空間接頭辞に結合されている名前空間URIである。もしそれが相対URIであれば，展開名における名前空間URIのように，解決していなければならない。
これを次に置き換える。
名前空間ノードの文字列値は，その名前空間接頭辞に結合されている名前空間URIとする。XML文書の中の名前空間宣言に出現している名前空間名が(素片識別子をもつ又はもたない)相対URIとなる場合，文字列値は，実装依存とする。それら名前空間ノードの文字列値に依存するXPath式は，相互運用可能ではない。
5.7 テキストノード
次を，最後から2番目の段落に追加する。
文書要素の外の空白は，テキストノードを生成しない。
[1] TR X 0048:2001, XSL変換(XSLT) 1.0, 2001-07
[2] XML Path Language (XPath) Version 1.0 Specification Errata, W3C, 2001-11
この標準情報(TR)原案を作成した(財)日本規格協会 情報技術標準化研究センター(INSTAC)の電子出版技術調査研究委員会及び作業グループWG1の委員構成を, それぞれ解説表5.1, 解説表5.2に示す。
| 氏名 | 所属 | |
|---|---|---|
| (委員長) | 池田 克夫 | 大阪工業大学 |
| (幹事) | 小町 祐史 | パナソニックコミュニケーションズ株式会社 |
| (幹事) | 大久保 彰徳 | 株式会社リコー |
| (幹事) | 長村 玄 | ネクストソリューション株式会社 |
| (幹事) | 高沢 通 | 大日本スクリーン製造株式会社 |
| (幹事) | 内山 光一 | 株式会社東芝 |
| 礪波 道夫 | 日本新聞協会(読売新聞社) | |
| 小笠原 治 | 社団法人日本印刷技術協会 | |
| 木戸 達雄 | 経済産業省産業技術環境局 | |
| (オブザーバ) | 高橋 昌行 | 経済産業省産業技術環境局 |
| (オブザーバ) | 三瀬 元康 | 日本新聞協会 |
| (事務局) | 内藤 昌幸 | 財団法人日本規格協会 |
| 氏名 | 所属 | |
|---|---|---|
| (主査) | 小町 祐史 | パナソニックコミュニケーションズ株式会社 |
| (幹事) | 内山 光一 | 株式会社東芝 |
| (幹事) | 大久保 彰徳 | 株式会社リコー |
| 奥井 康弘 | 株式会社日本ユニテック | |
| 内藤 求 | 株式会社シナジー・インキュベート | |
| 内藤 広志 | 大阪工業大学 | |
| 戸島 英一朗 | キヤノン株式会社 | |
| 長村 玄 | ネクストソリューション株式会社 | |
| (オブザーバ) | 浅利 千鶴 | 浅利会計事務所 |
| (オブザーバ) | 佐々木 徹 | アドビシステムズ株式会社 |
| (オブザーバ) | 藤島 雅宏 | 有限会社イー・エイド |
| (オブザーバ) | 高橋 昌行 | 経済産業省産業技術環境局 |
| (オブザーバ) | 山田 篤 | 財団法人京都高度技術研究所 |
| (事務局) | 内藤 昌幸 | 財団法人日本規格協会 |