この文書は「EPUB Canonical Fragment Identifier （epubcfi） Specification」の日本語訳である。最新の文書は http://idpf.org/epub/linking/cfi/epub-cfi.html である。原文もしくは完全な情報は、EPUB Canonical Fragment Identifier （epubcfi） Specification を参照されたい。
この日本語訳は参考である。公式な文書ではなく、翻訳・解釈の正確性を保証していない。
また本文内の訳注は翻訳者の主観による補足である。
1.2. 用語と EPUB Publications 3.0.1 - 1.2. 用語に定義されている用語は本文中でも基本的に原文のままとした。
2014年6月26日 Recommended Specification
以前のドラフトからの変更点の差分もまた利用できる。
この文書（いくらかの規範的な訂正を含むかもしれない）のために、正誤表を参照されたい。
Copyright © 2010, 2011 International Digital Publishing Forum™
無断複写・転載を禁止する。本作品は合衆国法典第17編の下に保護されている。変更を伴うこの著作物の複製と頒布は、International Digital Publishing Forum （IDPF）の書面による許可を得ない限り禁止されている。
EPUBは International Digital Publishing Forum の登録商標である。
このセクションは有益な情報である。
この仕様、EPUB Canonical Fragment Identifier（epubcfi）は、フラグメント識別子を使って EPUB® Publication の任意のコンテンツを参照する標準方式を定める。
Web は、ハイパーリンクのコンセプトが非常に効果的であることを証明しているが、EPUB 出版物は、内部へリンクする標準化された方法がないためハイパーリンクの多くの恩恵を利用できないでいる。個々のリーディングシステムは独自の方法を開発・実装しているが、共通に理解できる構文がなくてはクロスプラットフォームの相互運用性を実現することはできない。しかし、この障壁を取り除くことによって恩恵を受けることのできる機能は様々である。読書中の位置の保持からナビゲーションへの注釈付けなど、どんな出版物の内部を指すことのできる機能は、開発者と製作者にこれまで利用できなかった全く新しい次元を開く。
この仕様は、EPUB 出版物内のどのようなロケーションあるいはロケーションの単純な範囲でも一意に特定できる任意の構造参照（即ち、EPUB CFI）を定義してこの状況の改善を試みる。以下の配慮がこのスキームの設計と適応範囲に著しく影響する：
コンテンツ参照に使用するメカニズムは相互運用可能にするべきで（should）、ひとつのリーディングシステムで作成された読書中の位置は他のシステムでも利用できるようにするべきである（should）
EPUB コンテンツへのドキュメント参照は、既存のハイパーリンクが Web 全般で参照できるのと同じ方法で使用できるべきである（should）。
EPUB ファイル内のそれぞれのロケーションは、ドキュメントを変更する必要なく特定できるべきである（should）。
同じ論理ロケーションを参照するすべてのフラグメント識別子は比較したとき等しくなるべきである（should）。
ソートおよび比較の検証を含む比較演算は、参照先ファイルへのアクセスなしに行えるべきである（should）。
簡単な処理は元ファイルへのアクセスなしにできるべきである（should）。（例えば、ファイル内部への深層参照がある場合、ファイルの先頭への参照は簡単な処理で生成できるべきである（should）。）
識別子の解決は合理的に効率化されているべきである（should）。（例えば、最終章をポイントするフラグメント識別子の解決に第一章の処理は要求されない。）
参照のターゲットロケーションはパーサーの変化やドキュメントの改版を経て修復できるべきである（should）。
簡潔で切れ目のない表現をサポートするべきである（should）。
将来の参照を修復する発見的解決法に適応できる拡張可能なメカニズムを提供すべきである（should）。
Standard EPUB CFI と Intra-Publication EPUB CFI の両方の場合、この仕様は、セクション6 Best Practices for Fragid Structures [FragIDBestPractices] で W3C によって示されているガイドラインに準拠する。
言い換えれば、standard CFI URI （例えば、メディアタイプ "application/epub+zip" を参照する "book.epub#epubcfi(…)"） と intra-publication CFI URI （例えば、メディアタイプ "application/oebps-package+xml"を参照する "package.opf#epubcfi(…)"）の両方が、前述のメディアタイプ接頭辞登録（すなわち、"-xml" と "-zip"）のコンテクスト内の既存スキーマと重複しないフラグメント識別子の構文を利用する。
この仕様で使われる EPUB 固有の用語の定義については EPUB 仕様書を参照されたい。
出版物レベルの EPUB CFI は、EPUB 出版物の内部へリンクする。EPUB CFI に先行するパスは EPUB 出版物のロケーションを参照する。
Intra-Publication EPUB CFI は、一つの Content Document が同じ EPUB 出版物の Rendition 内の他のドキュメントを参照できるようにする。EPUB CFI に先行するパスはその Rendition の Package Document を参照する。
詳しくは Intra-Publication CFI を参照されたい。
次の表記上の規則は、この仕様に用いられる：
markupすべてのマークアップ（要素、属性、プロパティ）、コード（JavaScript、擬似コード）、機械処理可能な値（文字列、文字、メディアタイプ）とファイル名は、赤橙色の等幅フォントで示している。
markupマークアップとコードの定義へのリンクは、下線と赤橙色の等幅フォントで示している。各セクションの最初のインスタンスのみリンクがされている。
http://www.idpf.org/URI は紺色の等幅フォントで示している。
ハイパーリンクは、青い下線で示している。
規範的で参考情報は、角括弧で囲まれている。
用語集で定義されている用語は、キャピタルケースで示している。
用語の定義へのリンクはL、点線の青い下線である。各セクションの最初のインスタンスのみリンクがされている。
規範的な要素、属性とプロパティの定義は、青いボックスにある。
有益なマークアップ例は、白いボックス内にある。
有益な注記は、"Note"の見出しがある黄色いボックス内にある。
有益な警告は、"Caution"の見出しがある赤いボックス内にある。
このセクションは有益な情報である。
フラグメント識別子は、リソース内のロケーションを定義する IRI [RFC3987] の一部である。構文的には、リソース IRI の終わりに付属するハッシュ(#)で始まるセグメントである。HTML ドキュメントには、ID および名前付きアンカーがフラグメント識別子として使用されている。XML ドキュメントには、ID を参照するために Shorthand XPointer [XPTRSH] の表記が用いられている。
Canonical Fragment Identifier（CFI）は、これらと似たような構成であるが EPUB 出版物内部のロケーションを表現する。例えば：
book.epub#epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)
ハッシュの直後に続く関数のような文字列（epubcfi(…)）は、このフラグメント識別子がこの仕様の定義するスキームに従っていることを示し、括弧で囲まれた値は特定の EPUB 出版物（book.epub）内部のロケーションを参照するのに使われる構文である。パスの解決によって定義された処理ルールを使って、リーディングシステムは構文を解析し、EPUB 出版物の中の該当する Content Document を開いて、指定されたロケーションを消費者のために読み込むことができる。
EPUB CFI 構文の完全な定義は次のセクションに規定されている。
あらゆる XML+ZIP ベースのファイルフォーマットのための、より汎用的な CFI のようなスキームが将来定義されるかもしれないため、スキーム名の先頭に epub を付加している。
Unicode 文字
利用できる Unicode 文字の定義は [XML] と同じである。これには、サロゲートブロック、FFFE、および FFFF を除く：
#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
ドキュメントの著者は、[Unicode] のセクション 2.3 で定義される「互換文字」を避けることを推奨する。次の範囲で定義される文字も使用しないことを推奨する。これらは、制御文字または恒久的に未定義な Unicode 文字である：
[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDEF], [#x1FFFE-#x1FFFF], [#x2FFFE-#x2FFFF], [#x3FFFE-#x3FFFF], [#x4FFFE-#x4FFFF], [#x5FFFE-#x5FFFF], [#x6FFFE-#x6FFFF], [#x7FFFE-#x7FFFF], [#x8FFFE-#x8FFFF], [#x9FFFE-#x9FFFF], [#xAFFFE-#xAFFFF], [#xBFFFE-#xBFFFF], [#xCFFFE-#xCFFFF], [#xDFFFE-#xDFFFF], [#xEFFFE-#xEFFFF], [#xFFFFE-#xFFFFF], [#x10FFFE-#x10FFFF].
Canonical Fragment Identifier（CFI）は、この特殊な参照方法を示す初期シーケンス epubcfi と括弧に囲まれたパスまたはレンジによって構成される。パスは、ロケーションを参照する構造化されたステップのシーケンスとして組み立てられる。レンジは、開始と終了を指定する２つのローカル（または相対）パスを後ろに持ったパスである。
ステップは、スラッシュ文字 (/) によって示され、XML コンテンツの横断に使用される。CFI パス内の最後のステップは、構造（XML 要素）、テキスト（文字データ）または聴覚・視覚（画像または音声、動画メディア）どちらかの文書内の位置を表現する。そのような終端のステップは、特定の文字位置、時間的または空間的な断片を示す省略可能な "offset" によって補完されてもよい（may）。
括弧内の従属文字列は、伸長可能なアサーションであり、パスの移動や、同じ文書の異なる版へのパスの移行の精度を向上させる。これらのアサーションは、ドキュメント内でたどる要素に関する付加情報を保持しており、EPUB 出版物が変更されても目的のロケーションを修復することが可能になる。
上記の構文で定義される value はどのような文字のシーケンスでも許可するが、次に示す文字には曲折アクセント記号（^）を使ってエスケープし、解析を妨げぬようにしなければならない（must）：
角括弧 ([,])
曲折アクセント記号 (^)
コンマ (,)
丸括弧 ((,))
セミコロン (;)
テキスト "2[1]" の後ろのロケーションを指す EPUB CFI の例。
epubcfi(/6/14[chap05ref]!/4[body01]/10/2/1:3[2^[1^]])
パスとレンジの中での数字と整数の利用には次のルールが適用される：
数字または整数の前に来るゼロは利用できない（一意性を保証するため）。
数字の小数部分の末尾のゼロは利用できない。
ゼロは整数 0 で表現しなければならない（must）。
1 > N > 0 のレンジの数字は 0. で始めなければならない（must）。
整数（integral numbers）は整数（integers）で表さなければならない（must）。
構文で説明されているように、EPUB CFI の文法にはフラグメント識別子の表記の中の区切り文字となる特殊用途を持つ文字がある。これらの文字は、区切り文字として使用する意図がないとき、区切り文字に誤読されることなく EPUB CFI データの中で使用できるように、曲折アクセント記号 '^' 文字でエスケープしなければならない（must）。そのような EPUB CFI の使用コンテクストに応じて、さらなる文字エスケープを、すべての潜在的に矛盾するテキストトークンが正しくエンコードされるのを保証するために求めてもよい（may）。
IRIとURI参照：
EPUB CFI（フラグメント識別子）スキームは URI および IRI 参照内で使用されるように設計されている。[RFC3986] の仕様では区切り文字として特殊用途を持つ多数の“予約”文字を定義しており、もしそれらが URI/IRI 参照の構文構造と衝突する場合にはエスケープしてもよい（may）。エスケープにはパーセント記号 '%' を使用し、エスケープ可能な文字はパーセントエンコーディングされる。例えば、パーセント記号はエスケープエンコードされると "%25" となる（EPUB CFI の曲折アクセント記号 '^' と、二重文字 '^^' を使用してエスケープするところの違いに注意されたい）。
IRI 参照とは異なり、URI 参照は Unicode 文字を ASCII エンコードする必要がある。EPUB 仕様自体は IRI に基づいている（つまり、著者や制作ツールは IRI を使用することを想定している）が、いくつかのシステムや API は URI のみのサポートでもよい（may）。その結果、実装者は、[RFC3987] で定義されている IRI から URI 参照の変換処理をさらに必要としてもよい（may）。禁止文字は次のようにエスケープする：
(X)HTML コンテキスト：
IRI 参照は、EPUB 出版物を構成するさまざまな種類のドキュメントで使用されるように設計されている。XML および XHTML は、独自の文字エスケープ規則を必要とする別の挿入コンテキストを意味する。例えば、二重引用文字または山括弧は、マークアップ構文内で重要な区切り文字と競合するので、 &xxx; 特殊シーケンス（文字参照）を使ってエスケープしなければならない（must）。
文字エスケープを複数回適用して、EPUB CFI をエスケープまたはエスケープの解除をする場合、元の形式に戻すにはその逆の順序で適用しなければならない（must）。例えば、[ EPUB-CFI -> IRI -> XHTML ] ならば、 [ XHTML -> IRI -> EPUB-CFI ] の適用順序となる。
次の例は、（曲折アクセント記号 '^' によるエスケープだけの）EPUB CFI の「未加工」の形を示している。最後部のアサーションテキスト、およびエスケープされた左右角括弧と曲折アクセント記号に注目されたい（エスケープされていないテキストは 'Ф-"spa ce"-99%-aa[bb]^'である)：
epubcfi(/6/4!/4/10/2/1:3[Ф-"spa ce"-99%-aa^[bb^]^^])
IRI で使用される場合、アサーション内の空白文字はパーセントエスケープ ('%20') してもよい（may）。また、パーセント文字自体はエスケープ（'%25'）しなければならない（must）。角括弧 '[' ']' とセミコロン ':' は（URI の仕様によれば）「予約」文字となっているが、IRI プロセッサーがフラグメント識別子を抽出する際の区切り文字としては意味も持たないため、エスケープする必要はない。（つまり、IRI のフラグメン構成部品は、 '#' 文字以降のテキストすべて処理して曖昧さなく解析できる。）曲折アクセント記号 '^' もまた “賢明はでない”（または “安全ではない”）文字の部類に属するが、EPUB フラグメント識別子のスキームではエスケープする必要はない。次は IRI のエスケープされた EPUB CFI である：
#epubcfi(/6/4!/4/10/2/1:3[Ф-"spa%20ce"-99%25-aa^[bb^]^^])
XML 属性の中に IRI を指定する場合、二重引用文字（引用符）は属性値の区切り文字として重要であるため '"' にエスケープする。 キリルの “EF” 文字（'Ф'）は EPUB XML ドキュメントでそのままサポートされていることに注目されたい。EPUB XML ドキュメントは（UTF-8 エンコーディングを使って Unicode 文字のレパートリーを表現するため）エンコードする必要はない：
#epubcfi(/6/4!/4/10/2/1:3[Ф-"spa%20ce-99%25"-aa^[bb^]^^])
IRI を URI に変換する必要がある場合、非 ASCII のキリルの “EF” 文字 ('Ф') は2バイト (16 進数で、'0xd0 0xa4') へパーセントエスケープする。結果として次のような URI となる：
#epubcfi(/6/4!/4/10/2/1:3[%d0%a4-"spa%20ce"-99%25-aa^[bb^]^^])
URI エンコード／デコード API は、次の例に示すとおり、通常「強引に」パーセントエンコードを行う。曲折アクセント記号 '^'（%5E）、角括弧 '['（%5B）']'（%5D）、二重引用符 '"'（%22）が、（URI の中では “安全ではない”／“賢明はでない” 性質を持つため）どのようにパーセントエンコードされるかにも注意する必要がある：
#epubcfi(/6/4!/4/10/2/1:3%5B%D0%A4-%22spa%20ce%22-99%25-aa%5E%5Bbb%5E%5D%5E%5E%5D)
EPUB CFI を EPUB 出版物内のロケーションへ解決する処理は、Package Document の package ルート要素から開始する。CFI のそれぞれのステップは、次のサブセクションで定める規則を適用しながら、左から右へひとつずつ処理される。
以下のサブセクションでの EPUB CFI の例は、用例のサンプルドキュメントに基づく。
/)正の整数が続くスラッシュ (/) のステップは、ここに定義してある規則ごとに、子要素や文字データのチャンクを参照する：
要素と文字データ以外の [XML] コンテンツは、無視される。[XML] 仕様に従って、CDATA セクション内に文字データは包含され、逆に言えば、XML コメントは無視されることに注意されたい。
（一般的に、マークアップのフォーマットやインデントのために使用された）無意味な空白に対応する [XML] 文字データは、保持される。文字とエンティティの参照は、拡張とみなされ、文字データは、（[XML] 仕様に定義された用語に従って）"包含された代替えテキスト"から得られる。
兄弟子要素（すなわち、"混在したコンテンツ"のコンテクスト）の間に散りばめられた [XML] 文字データは、論理的に連続した文字データの（潜在的に空の）チャンクに構成されており、最初のチャンクは、最初の子要素（左の兄弟）の前に配置され、最後のチャンクは、最後の子要素（右の兄弟）の後に配置され、子要素の各ペアの間のひとつのチャンクがある。子要素が存在しないとき、文字データのいずれか（潜在的に空の）チャンクがある。文字データの連続した（潜在的に空の）チャンクは、それぞれ割り当てられた奇数のインデックス（すなわち、1 から始まり、3…と続く）である。
子 [XML] 要素は、それぞれ割り当てられた数のインデックス（つまり、2 から始まり、4…と続くである。さらに、0 は、親要素のコンテンツ内の文字データの最初の潜在的に空のチャンクの実質的に前に来る存在しない要素を参照する妥当なインデックスである。同様に、n+2 は、文字データの最後の潜在的に空のチャンクに実質的に続く存在しない要素を参照る妥当なインデックスであり、これらが子要素を持たないとき、n は、最後の子要素または 0 の偶数のインデックスである。CFI プロセッサ（例えば、リーディングシステム）は、文字データの最初（もしくはそれぞれ最後）のチャンクが空のときでさえ、0 と n+2 の"仮想"要素への参照を含んでいる CFI 表現を消費する（例えば、構文解析と解釈）ことができなければならない（must）。逆に言えば、そのような CFI 表現の*生産物*は、次の適合性要件によって制御されなければならない：文字データの最初のチャンクが空のとき、CFI 表現は、インデックス 0 の"仮想"要素への参照を使用して構成されるべきではなく（shouled not）、代わりに"実在の"最初の子要素（インデックス 2 のとき）は、参照するべきである（should）。同様に、文字データの最後のチャックが空のとき、CFI 表現は、インデックス n+2 のとき"仮想"要素への参照を使用して構成されるべきではなく（shouled not）、代わりに、"実在の"最後の子要素（インデックス n のとき）は、参照するべきである（should）。
"仮想"の最初/最後の要素のメカニズムは、存在しない要素が、最初と最後の境界で文字オフセットに依存することなくテキストコンテンツを横断して使用される DOM 範囲のいくつかのインスタンスの相互互換性を容易にするかもしれない。
Standard EPUB CFI では、CFI の先頭のステップは斜線（/）とそれに続く（Package Document の package ルート要素の spine 子要素を参照する）偶数の番号で始まらなければならない（must）。CFI がたどる Package Document は、EPUB 出版物の META-INF/container.xml ファイルの中の Default Rendition として指定されていなければならない（must）。（つまり、 container.xml の最初の rootfile 要素で参照される Package Document であること。）
Intra-Publication EPUB CFIでは、最初のステップは斜線とそれに続く（package 要素から始まる Package Document 内の位置を参照する）ノード番号で始まらなければならない（must）。
[）EPUB CFI が、ID [XML] を含んだ要素を参照する場合、該当するパスのステップは、（斜線（/）と要素を特定する偶数の後ろに）角括弧で囲んだその ID を含めなければならない（must）。
識別子の仕様は、CFI のスキームを堅牢にする。リーディングシステムは CFI で参照された位置が最初に目的とした位置でないと判断してもよく（may）、コンテンツ内の求められる目的の箇所に到達するステップのセットを計算するために識別子を使用してもよい（may）（ターゲットロケーション補正を参照されたい）。この追加された堅牢性のコストは、CFI 文字列の比較（とソート）はすべての括弧で囲まれた文字列を論理的に除去した後でのみ実行してもよい（may）（ソート規則を参照されたい）。
!)ステップまたはステップの連続が、他のドキュメントを参照する要素への点であるとき、感嘆符 (!) は、そのステップが参照した文書（"間接"）に適用される表現がすぐに続くときはいつでも、使用されなければならない（must）。次の表現は、参照した XML ドキュメントのルート要素または（特定の）ターゲットしたXMLフラグメントから解決される。
次の参照のみが有効である：
:)先頭のコロン（:）とそれに続く整数のパスの終端は文字オフセットを参照する。指定された文字オフセットの要素ノードへの適用は、その要素が [HTML5] img 要素であり、文字オフセットを適用できるテキストを含んだ alt 属性を持つ場合のみ行なってもよい（may）。
XML character data では、オフセットはゼロベースで常に文字の間の位置を参照する。従って、0 は最初の文字の前を意味し、UTF-16での全長の数は最後の文字の後ろを意味する。使用できるテキストの UTF-16 の長さよりも大きな文字オフセット値を指定してはならない（must not）。
文字オフセット終了ステップは /N ステップに続く場合のみ指定してもよい（may）。XHTML Content Document では、N は img 要素の alt のテキストを参照している時は偶数で、要素内のXML character data を参照している時は奇数となる。
奇数番号の /N ステップを持つ終端の CFI 表現は、明示的な文字オフセットを包含するべきである（should）。なぜならば、CFI プロセッサ（例えば、リーディングシステム）は、オフセットの暗黙的な /N:0 文字と仮定すれば、そのような CFI 表現を消費（つまり、構文解析と解釈またはレンダリング）ができなければならない（must）。
~)先頭のチルダ (~) とそれに続く数字のパスの終端は、オーディオまたはビデオの秒単位の時間位置を示している。
時間オフセット終了ステップの後ろに他のステップを続けることはできない。
@)コロン区切りの二つの数字に従う先頭のアットマーク（@）から続くパスの終端は、画像またはビデオの二次元空間位置を示す。二つの数字は x 軸と y 軸のスケーリングされた位置を表し、画像のネイティブまたは表示サイズに関わらず 0 から 100 の範囲でなければならない（must）。（つまり、左上は 0:0 で右下は 100:100 となる。）
~ + @)時間位置と空間位置は同時に使用してもよい（may）。この場合、時間指定は空間指定よりも構文的に前に置かなければならない（must）。（例えば、~23.5@5.75:97.6 は、ビデオの 23.5 秒のフレームの左下を参照する。）
[）EPUB CFI は、一致箇所の前および／または後ろに予期されるサブストリングを指定してもよい（may）が、そのようなアサーションの指定は character offset の後ろのみでなければならない（must）。
例えば、後述するサンプルコンテンツを使った次のアサーションは、一致箇所の直前に yyy が必要であることを表している。
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[yyy])
一致箇所に続くサブストリングをコンマの後ろに追加することができる。例えば：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[xx,y])
これは、アスタリスクの付いた箇所を参照している：
x x x y y y 0 1 2 3 4 5 6 7 8 9 | | | * | | | | | | | | | | | |
先行するテキストがない場合、または後続のテキストだけが指定される場合、テキストアサーションの直前にコンマを付けなければならない（must）：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[,y])
マッチさせるために含むことのできる、先行または後続のテキストの長さに制約はない。テキストは、ドキュメントから要素の境界を無視して取り出され、空白文字は常にまとめられる。（つまり、空でない連続する空白文字列は常に単一の空白文字に置換される。）
リーディングシステムは、（テキストがマッチしないために）CFIで参照されるロケーションが本来の目的のロケーションではない、と判断してもよく（may）、コンテンツ内の目的となる宛先に到達する一連のステップを計算するために、先行／後続のテキストを利用してもよい（may）（ターゲットロケーション補正を参照されたい。）。この追加された堅牢性のコストは、CFI 文字列の比較（とソート）はすべての括弧で囲まれた文字列を論理的に除去した後でのみ実行してもよい（may）（ソート規則を参照されたい）。
[ + ;s=）状況によっては、参照がロケーションのどちらの側を指しているのか、という情報の保持が重要となる。例えば、動的にページを作成する環境でロケーションを解決する場合、ロケーションが前のコンテンツに属している場合と後のコンテンツに属している場合では違いがある。（例えば、改ページに際して、ページの表を表示するのか裏を表示するのか判断する場合。）
ロケーションのサイド情報を保持するには s パラメータを使用する。s は、二つの値をとることができ、'b' ("前（before）") は、ロケーションは、（XML シリアライゼーション文書の順番に従い）先にあるコンテンツに接続されることを意味し、'a' ("後（after）") は、次のコンテンツを参照する。このパラメーターは、ID [XML] またはテキストロケーションのアサーションが空の場合でも、常に CFI の最後部で角括弧で囲んで使用しなければならない（must）。
後述のサンプルコンテンツにおける yyy の直後のロケーションが前のコンテンツに属することを、次のように表すことができる：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[;s=b])
同様に、次のようにテキストロケーションアサーションを含めて指定することもできる：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[yyy;s=b])
em 要素の先頭のロケーションを、その em 要素に先行するコンテンツに付加することは、次のように表すことができる：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2[;s=b])
前述の例において、サイド指定に b ではなく a を指定していた場合、ロケーションは、em 要素の次のコンテンツではなく、em 要素の子コンテンツに付加される。
サイド指定はパラメータとして表現されるため、CFI の比較には関与しない（ソート規則を参照されたい。）
サイドは空間のオフセットへのロケーションには定義されない。
サイド指定は、ロケーションで何らかのブレークが起こる場合にのみ意味を持つ（例えば、改ページや改行。）
このセクションは有益な情報である。
次ような Package Document があるとする:
<?xml version="1.0"?>
<package version="2.0"
unique-identifier="bookid"
xmlns="http://www.idpf.org/2007/opf"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:opf="http://www.idpf.org/2007/opf">
<metadata>
<dc:title>…</dc:title>
<dc:identifier id="bookid">…</dc:identifier>
<dc:creator>…</dc:creator>
<dc:language>en</dc:language>
</metadata>
<manifest>
<item id="toc"
properties="nav"
href="toc.xhtml"
media-type="application/xhtml+xml"/>
<item id="titlepage"
href="titlepage.xhtml"
media-type="application/xhtml+xml"/>
<item id="chapter01"
href="chapter01.xhtml"
media-type="application/xhtml+xml"/>
<item id="chapter02"
href="chapter02.xhtml"
media-type="application/xhtml+xml"/>
<item id="chapter03"
href="chapter03.xhtml"
media-type="application/xhtml+xml"/>
<item id="chapter04"
href="chapter04.xhtml"
media-type="application/xhtml+xml"/>
</manifest>
<spine>
<itemref id="titleref" idref="titlepage"/>
<itemref id="chap01ref" idref="chapter01"/>
<itemref id="chap02ref" idref="chapter02"/>
<itemref id="chap03ref" idref="chapter03"/>
<itemref id="chap04ref" idref="chapter04"/>
</spine>
</package>
また、XHTML Content Document の chapter01.xhtml はこのような内容となっている：
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>...</title>
</head>
<body id="body01">
<p>…</p>
<p>…</p>
<p>…</p>
<p>…</p>
<p id="para05">xxx<em>yyy</em>0123456789</p>
<p>…</p>
<p>…</p>
<img id="svgimg" src="foo.svg" alt="…"/>
<p>…</p>
<p>…</p>
</body>
</html>
この場合、次のEPUB CFIは
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)
ID が para05 の段落の 9 の数字の直後の位置を参照する。テキストのロケーションの CFI を作成する時、テキストが img 要素の alt タグに定義されていなければ、常にロケーションに該当するXML character dataの（おそらく空である）チャンクへの参照から開始し、Package Document のルートまで祖先と参照チェーンをたどるべきである（should）。
次の例は、更なるコンテンツロケーションを参照する EPUB CFI の構成を示す：
img 要素のへ参照
epubcfi(/6/4[chap01ref]!/4[body01]/16[svgimg])
xxx の直前の位置への参照
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/1:0)
yyy の直前の位置への参照
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:0)
yyy の直後の位置への参照
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3)
同じ EPUB 出版物を参照する複数の EPUB CFI の相対的なロケーションを、ソートしたり計算したりするには、次のルールに従わなければならない（must）：
EPUB CFI スキームデータは、文字エスケープで説明されているルールの通りに、アンエスケープされた形式でなければならない（must）。
すべての角括弧で囲まれたアサーションは完全に除去（無視）される。
シーケンスの中では、先に来るステップの方が重要である。
XML 要素は、XML character data、文字オフセットや時間位置のチャンクへの参照は、自然順序でソートする。
y 位置は x 位置よりも重要である。
省略された空間位置は他のすべての空間位置に先行する。
省略された時間位置は他のすべての時間位置に先行する。
時間位置は空間位置よりも重要である。
ステップの種類は、重要度の低いものから高いものへと、次のような順番となる：
文字オフセット（:）、子（/）、時間-空間（~ または @）、参照／間接指定（!）.
EPUB CFI は、コンテナ内部のコンテンツの参照に使用することができる。このような参照は、Package Document への参照とそれに続く CFI を指定して実現されるが、CFI の解決は package ルート要素から開始しなければならない（must）。
例えば、上記の例のPackage Document を使って、chapter01.xhtml の最後のロケーションへの参照は次のように記述できるだろう：
<a href="../pub.opf#epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/2/1:3[;s=b])">location</a>
EPUB CFI は、開始ロケーションから終了ロケーションまでの簡潔なレンジを表すことができる。レンジは parent パス（P）、start サブパス（S）、そしてend サブパス（E）の3つによって、次の形式で表さなければならない（must）：
epubcfi(P,S,E)
parent パスは、空であってはならず（must）、レンジの開始と終了のロケーションの両方のパスを解決するための共通のステップで終わらなければならず（must）、start と end のそれぞれのサブパスはドキュメント内で減少しない順序でロケーションへと解決しければならない（must）。
レンジの開始と終了ロケーションを決めるには、parent パスを start と end サブパスに連結して開始ロケーションパス（PS）と終了ロケーションパス（PE）を生成しなければならない（must）。
parent パスは、開始と終了パス（言い換えれば、開始と終了位置は、共通パスに含むべではない（should not））の両方に通じる可能な限り深い共通パスを包含するべきである（should）。
開始位置は、終了位置が開始位置に根付いたサブツリー内に位置している場合には、共通パスの繰り返しを避けるために空でもよい（may）。
上記のサンプルドキュメントを使った次のレンジは yyy の2番目の y から数字 3 まで（含めた）テキストを表す：
epubcfi(/6/4[chap01ref]!/4[body01]/10[para05],/2/1:1,/3:4)
レンジの比較は、それぞれの PS、次にそれぞれの PE の構成部品によって行わなければならない（must）。
開始と終了位置は、要素と文字オフセット（ドキュメント構造）や時間的オフセット（時間メディア）、空間的オフセット（視覚メディア）、一体化した時空間的オフセットと呼ばれる同じ"特定"を持つドキュメント内の点を参照するべきである（should）。時間的オフセットの場合、開始と終了の位置は、同じ時間メディアを参照するべきである（should）。空間的オフセットの場合、開始と終了の位置は、同じ視覚メディアを参照するべきである（shouled）。この仕様は、このような二つの時空間的オフセット（すなわち、視覚メディア内の開始と終了位置）の組み合わせが、制作ツールやリーディングシステムを含め、処理エージェントによってどのように解釈されるかの、期待する挙動を定義しない。
要素の最初から最後までのレンジを表すショートハンドとして要素へのパスを使用するのは適切ではない。単独で表記されたパスは常にロケーションの位置（ポイント）を表し、レンジは上記で解説した表記で表す。要素の終わりへの参照を示す特殊なステップが存在しないのは、それによってドキュメントのコンテンツを調べることなくソートするのが不可能になるためである。
コンテキストで単独のロケーションが指定されるべきところにレンジが使用された場合、その開始ロケーションを使用しなければならない（must）。
サイド指定パラメータをレンジに使用してはならない（must not）。レンジの開始は暗黙的に開始ロケーションンの後ろのコンテンツに属し、終了は暗黙的に終了ロケーションの前のコンテンツに属する。
EPUB 出版物は時間とともに改訂、修正、或いは変更されてもよく（may）、以前のバージョンの CFI から変更されたドキュメントの EPUB CFI を導き出すことは有用である。この仕様は、CFI に影響するコンテンツの変更を発見し補正する二つのメカニズムを提供している。それは、ID [XML] とテキストロケーションアサーションである。
リーディングシステムが CFI を処理する際には、遭遇するすべてのアサーションの正確さをチェックするべきである（should）。例えば、/6/4[chap01ref]!…のパスを例にすると、リーディングシステムは、要素 4 の処理中にその要素は chap01ref に一致する ID を持っていることを確認するべきである（should）。（この例では、spine 内の itemref が該当する）。もし確認できなければ、リーディングシステムはドキュメント内で chap01ref の ID を見つけて CFI を修正するべきである（should）。（例えば、新しい itemref が chap01ref の itemref の前に挿入された場合は、望ましい要素の番号は 6 となり、CFI は /6/6[chap01ref]!... に修正される）。同様に、テキストロケーションアサーションは、参照されるターゲットロケーションを確認し、望ましいテキストロケーションを指す正しい CFI を得るために使用するべきである（should）。
もし処理中にアサーションの一つが失敗し、CFI を修正できない（ドキュメント内に ID が存在しない、または一致するテキストが見つからない）場合には、その CFI は無効な参照と見なさなければならない（must）。リーディングシステムが正確性を検証できない（例えば、CFI の処理中にドキュメントに内在する XML ID が利用できない）場合には、リーディングシステムは CFI アサーションを無視しなければならない（must）。
CFI 補正という観念からは、二つの異なる CFI（修正前の “陳腐化した” CFI と修正された CFI）が、同じロケーションを指す状況が生まれることがある。可能であれば修正された CFI を使用するべきである（should）。リーディングシステムやそれに関係するコンテンツ管理システムは、可能であれば陳腐化した CFI を修正された CFI に置き換えることを試みるべきである（should）。
この仕様は、本来の機能が不十分である場合、CFI補正を支援するカスタム機能を開発することを推奨する。このような機能の開発方法の詳細はEPUB CFI の拡張を参照されたい。
拡張仕様（パラメータ名の接頭辞を持ち、セミコロンで区切られた、CSV パラメータリスト）は、リーディングシステムが、例えば、EPUB CFI フラグメントを更新されたドキュメントへ移行させるとき、手助けする新しいまたは実験的なヒューリスティックスを適用することを認めています。
拡張機能（パラメータ名の接頭辞を持ち、セミコロンで区切られた、CSV パラメータリスト）の提供によって、リーディングシステムは、例えば EPUB CFI フラグメントを更新されたドキュメントへ移行する際に、新規または実験的なヒューリスティックを適用することができる。
ベンダー固有のパラメータ名は、vnd. とそれに続くベンダー名で始めることを推奨する（recommended）。
実装は、解釈や構文解析できないあらゆるパラメーターを無視しなければならない（must）。
[RFC2119] Key words for use in RFCs to Indicate Requirement Levels (RFC 2119) . March 1997.
[RFC2279] UTF-8, a transformation format of ISO 10646 (RFC 2279) . January 1998.
[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax (RFC 2396) . August 1998.
[RFC2732] Format for Literal IPv6 Addresses in URL's (RFC 2732) . December 1999.
[RFC3986] Uniform Resource Identifier (URI): Generic Syntax (RFC 3986) . January 2005.
[RFC3987] Internationalized Resource Identifiers (IRIs) (RFC 3987) . January 2005.
[SVG] Scalable Vector Graphics (SVG) 1.1 (Second Edition). 09 June 2011.
[Unicode] The Unicode Consortium. The Unicode Standard..
[XML] Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 November 2008.
[FragIDBestPractices] Best Practices for Fragment Identifiers and Media Type Definitions.
[XPTRSH] XPointer Shorthand Notation.