XML断片の交換

提供: STUDIO DDT ONLINE
移動先: 案内検索

この文書はW3CがW3C勧告候補として公開している仕様書"XML Fragment Interchange"をSTUDIO DDT ONLINEが学習目的で日本語に翻訳したものです。正式な仕様書は英語版のみであり、この日本語訳は参考にすぎません

この文書には翻訳上の誤りが含まれるかもしれません。STUDIO DDT ONLINEは翻訳の正確性を保証しません。

この文書のレイアウトはMediaWikiの記法に依存するため、オリジナルの文書とは文書構成、HTMLのセマンティクス、見栄え等が異なります。

この文書は翻訳途中のまま、作業が停滞しています。

W3C勧告候補2001年2月12日

このバージョン
http://www.w3.org/TR/2001/CR-xml-fragment-20010212XML
最新のバージョン
http://www.w3.org/TR/xml-fragment
以前のバージョン
http://www.w3.org/1999/06/WD-xml-fragment-19990630.html http://www.w3.org/1999/06/WD-xml-fragment-19990630.xml
http://www.w3.org/TR/1999/WD-xml-fragment-19990412.html http://www.w3.org/TR/1999/WD-xml-fragment-19990412.xml
http://www.w3.org/TR/1999/WD-xml-fragment-19990303.html http://www.w3.org/TR/1999/WD-xml-fragment-19990303.xml
編者
Paul Grosso, Arbortext <pgrosso@arbortext.com>
Daniel Veillard, W3C <veillard@w3.org>

著作権© 2002 W3C®マサチューセッツ工科大学フランス国立情報処理自動化研究所慶應義塾大学)により、全ての権利が留保される。W3Cの免責商標文書利用ソフトウェア使用許諾規定が適用される。

概要

恐らく複数の実体から成る論理的な文書を、XML標準は裏付ける。文書の全体が閲覧や編集できなくとも、あるいは関心や必要がなくとも、文書の一部や一つ以上の実体を閲覧したり編集したりできることが望ましい。その時、コンテクストに関する適切な情報として、受け側が許容可能な文書より大きい断片が受け手に与えられるということが問題になる。XMLフラグメントワーキンググループは、断片が実体であると事前に定まっているかどうかを問わないにも関わらず、問い合わせに関して全ての文書を送信せずに、XML文書の断片を送信する方法の定義を与える。この文書は(最終的には)、この問題を解決するためのW3C勧告の初版を定義する。

この文書の位置づけ

この仕様書は、XMLコアワーキンググループによって勧告候補として提出されている。この仕様書は、最終草案の間に受けた提案、再検討、意見と、W3CのXMLフラグメントワーキンググループの更なる協議を組み込んだ1999年6月30日草案の改訂版である。この作業の背景のために、XML活動声明を参照されたい。ワーキンググループは、この期間中の実装意見からこの仕様書が確固たるものになると信じる。

勧告候補期間は約3ヶ月(2001年4月末まで)となる見込みである。誰しもが評価し、この仕様書を実装し、公に保存されるメーリングリストwww-xml-fragment-comments@w3.orgへ意見を返すことが推奨される。

この仕様書が実装することができないとわかったなら、ワーキンググループは文書を草案に差し戻し、必要な変更を行う。そうでないなら、ワーキンググループはこの文書を勧告案として提出し、W3Cの管理者への請求を早める。

未だに草案であるので、いつでも他の文書によって更新されたり、置き換えられたり、取り消されたりするかもしれない。W3C勧告候補は"進行中の作業"以上のものではない。W3C草案の現在の一覧はhttp://www.w3.org/TRで得られる。

要旨

恐らく複数の実体から成る論理的な文書を、XML標準は裏付ける。文書の全体が閲覧や編集できなくとも、あるいは関心や必要がなくとも、文書の一部や一つ以上の実体を閲覧したり編集したりできることが望ましい。その時、コンテクストに関する適切な情報として、受け側が許容可能な文書より大きい断片が受け手に与えられるということが問題になる。

多くのXML文書では、文書の一部だけを望んでも、次善の方策として完全な文書を受け取って解析しなければならない。ユーザが第20章を参照したいと問い合わせても、目的の部分へたどり着く前の19章全てを解析する必要はないだろう。この活動の目標は、問い合わせ中の一部までの全てを処理せずとも、XML文書の小片の処理を可能にする方法を定義することにある。文書の一部分が実体かどうかを問わずとも、この方法が実行され得るし、その一部分が、即座に参照されるか、または後で活用したり、構築したり、もしくは他で処理するために蓄積することのどちらかが可能となる。

考え方としては、元となる完全な文書の所有者がその文書の断片を考慮し、当仕様書によって定められる記法を用いて、断片コンテクスト設計(fragment context specification)を構築する。元文書から取り出されて断片として表されるオブジェクトは、断片主部(fragment body)と呼ばれる。断片コンテクスト設計と断片主部は受信側へ送信される。送信された断片主部中の保存オブジェクトは、断片実体(fragment entity)と呼ぶ。(ある実装の仕組みでは、断片コンテクスト設計も断片実体の中に埋め込んでもよい)受信側は、断片の先頭部にあるコンテクストのために適切なパーサ状態を決定して断片コンテクスト設計を処理し、XMLパーサが断片主部を解析できるようにその情報を用いる。("送信側"、"受信側"、"送信"という単語は、断片交換の過程を表すためにこの文書の至る所で用いられる。多くの適切で有用な断片交換のためのシナリオが存在することを気に留めておくべきだが、ある事例では"送信側"と"受信側"は同一の機器、ノード、システム、またはネットワークかもしれないし、別のガイドではまったく同じツールであるかもしれない)

課題は、XML文書から分離した要素が正確に解析するために必要な情報をまるで含まないかもしれないということである。

この仕様書の目的は、別々の実体として管理したり、あるいはコンテクストの喪失のためにあえて不正確な構文解析をせずとも、本や章から節・表・脚注・書名などに至るまで、システムが選択するあらゆるXML要素を交換できるように、残りの必須情報を送信側が与えられるようにすることである。

これらの目標を達成するために、この勧告は以下を定める。すなわち、

  • この勧告によって裏付けられることになる断片で構成される、あるXML文書の一部分に関する厳格な制約
  • 正常な構文解析だけでなく、有用で重要な事例集合中の断片の閲覧や編集も可能にする、情報(断片コンテクスト情報)一式
  • この仕様書で説明する記法(言い換えれば、言語)(断片コンテクスト情報)
  • この仕様書を断片に関連付けるための、ある機構

適用範囲

この勧告は、XML文書の一部分を(原本の文書コンテキストで構文解析したように)正確に構文解析でき、実用的な範囲で書式を整え、編集し、他の有用な方法で処理できるだけでなく、交換可能にする。

この仕様書の目的は、断片が実体であると事前に決っているかどうかに関わらず、問い合わせに一致する部分をすべて含んだ文書を送信せずともXML文書の断片を送信する方法を定めることにある。配送される部分は、その場で閲覧や編集すること、もしくは後で利用され、構築され、もしくは他の処理をするために蓄積することのどちらかを選んで実行できる。すなわち、受信するアプリケーションがこの仕様書の有効範囲を越えた情報を処理し、結果として元の送信者へ前述の断片を"返す"ことができる。この勧告の実装は"断片の再利用"(flagment reuse)を考慮する、より大きなシステムの一部として機能するであろうし、多くの重要な問題は、およそXMLテキストを再利用することと"複数同時生成環境"(concurrent multiple author environments)であって、この仕様書の適用範囲を越える。

断片コンテクスト情報の意義は、完全なXML文書では有効だが断片主部の中で有効でない情報を提供することにある。特に、(外部部分集合(external subset)を含むかもしれない)XML文書で利用できないあらゆる情報(その上、文書中の断片主部の場所の知識)は、総じて断片コンテクスト情報に含まれる範囲外である。そのような情報は、多様なアプリケーションで恐らく有用で重要なメタデータであるが、この情報を処理するための他の機構が存在する(必要がある)。

この勧告はXML 1.0[XML 1.0]とXML名前空間勧告[XML Namespaces]によって定義されたようなXMLの断片について検討する。当勧告のこのバージョンは、XMLスキーマワーキンググループでの議論を考慮に入れていないことに留意せよ。すなわち、現在活動中の他のワーキンググループによって、このような断片交換の解決方法に関する新たな要件を定めている場合、後にそれらの要件は断片交換仕様の新版に加えられるだろう。

この仕様書は整形式(well-formed)XMLでない情報の交換を考慮しないことに留意せよ。特に、(HTMLを含む)SGMLの断片交換に特有の問題については、実際に整形式XMLでもあるようなSGMLを除いて、この仕様書の適用範囲ではない。

用語

この一覧はアルファベット順ではなく"論理的に"並べられている。本文中の丸括弧の文句は"任意"であることを表している。すなわち、それらが明確に利用されていようといまいと、この勧告の目的は変わらない。

(整形式)XML文書
(well-formed)XML document
XML 1.0勧告[XML 1.0]整形式(Well-formded)XML文書で定義済み。
(整形式の)(外部)(解析対象)実体
(well-formed)(external)(parsed)entity
XML 1.0勧告[XML 1.0]生成規則[78] extParsedEntで定義済み。
(良く)安定した
(well-)balanced
XML文書のある範囲(連続した文字列)が、XML 1.0勧告[XML 1.0]生成規則[43] contentに適合するなら、(良く)安定している、と言う。参考までに言うと、これは、その範囲があらゆる構成のマーク付けのあらゆる部分を含むなら、その範囲はその構成のマーク付けの(すなわち、要素に関しては、開始タグと終了タグの)全てを含むことを意味する。
断片
fragment
主として、他のXML文書がなくとも交換と利用に役立つかもしれない、いくつかの追加情報を加えた、あるXML文書の一部分を指す言葉である。より厳密な定義が求められるときは、後述する断片に関する用語を参照せよ。
断片の交換
fragment interchange
断片を解釈可能なアプリケーションによる、断片の受信、あるいは構文解析の処理。
断片主部
fragment body
断片を定義した目的から、(論理的、または物理的に)残りの文書から分離しているとみなされる、XML文書のある安定した範囲。完全なXML文書から取り出された、安定した範囲で構成される断片実体の一部分も同様である。ある参照が、未だに元の(親)文書の物理的な一部分である断片主部の変形であることを明確に指し示すために重要であるので、この仕様書は"あるがままの断片主部"(fragment body in situ)という用語を用いるだろう。
コンテクスト情報
context information
XML文書を処理しているパーサが、断片主部(になる予定)の先頭文字に遭遇した時点(ただし、未だ処理されていない)で、あらゆる特定の言語・文法・記法から分離した、"構文解析状態"(parser state)を定める情報の抽象的な集合。
(断片)コンテクスト(情報)
(fragment)context(information)
任意の断片コンテクスト設計言語(fragment context specification language)で表現されると思われる、コンテクスト情報の部分集合(略記するとfci)。特定の断片コンテクスト設計によって表された情報の、抽象的な集合も同様である。
断片コンテクスト設計
fragment context specification
断片コンテクスト情報を記述する、この勧告で定義する言語(記法)に沿った妥当な文字列(略記するとfcs)。
パッケージする [動詞]
package [verb]
断片コンテクスト設計と断片主部を、何らかの秩序だった方法で関連付けること。これは、両者を単一の符号化済みXMLオブジェクトに結合する何らかの方法を含むだろう。すなわち、いくつかのマルチパートMIME、または符号化の記録の両方を一体化する、または、参照、同一指示、または第三者の参照の枠組みのような何かを経て二者を結びつける。
断片実体
fragment entity
断片交換の処理の間、断片主部が記録され、もしくは送信される場合の容器となるオブジェクト。
(断片)パッケージ [名詞]
(fragment)package [noun]
断片交換の処理の間、実際に送信されるオブジェクト。にもかかわらず、これは断片実体と同じものであると思ってよい。この用語は全ての場合で同義語となるかもしれないし、ならないかもしれない。すなわち、断片パッケージが断片コンテクスト設計となって、かつ断片実体は後で送信させる場合は、断片コンテクスト設計が断片主部なしで送信される(恐らく後で送信させる)ようなパッケージの機構を、誰でも定義することができる。
断片コンテクスト設計文書
fragment context specification document
この勧告で定められているような、整形式XML文書となる妥当な断片コンテクスト設計(fcs)。従って、ある文書を考えるとき、fcsは時に断片コンテクスト設計文書(fcs文書)として参照される。断片コンテクスト設計文書も断片パッケージ(すなわち、断片交換結果として送信される実オブジェクト)となってよい。
送信/受信(送信側/受信側)
send/receive (and sender/recipient)
この勧告の文脈では、送信/受信(送信側/受信側)という単語は、断片交換の一般的な処理を記述するものである。断片交換のための実現可能で有用な筋書きがあり、その中のある事例では、"送信側"と"受信側"は同一の機器、ノード、システム、またはネットワークかもしれないし、別のガイドではまったく同じツールであるかもしれない。唯一普遍の前提は、送信側は断片の元となる完全な(親)文書を理解し、アクセスできることと、受信側は断片パッケージを所有するのみである(この勧告には記載しないが、送信側からより多くの情報を取り寄せようすることが可能であるなら、受信側は断片パッケージ中の情報をまったく利用しない)ことである。

断片コンテクスト情報の一式

今節において、角括弧の中の数字は、XML1.0勧告[XML 1.0]の生成規則を参照する。以下の情報が、完全な断片コンテクスト情報(fcs)の一式を構成するだろう。

  1. ExternalID [75]を明確にすることによる、外部部分集合(external subset)(extSubset [30])への参照。
  2. 内部部分集合(internal subset)の情報は、次のいくつか、あるいは全てを用いる。すなわち、
    1. ExternalID [75]を明確にすることによる、(恐らく、extSubset [30]のように保存オブジェクトの中の内部宣言を置き換えることで作成された)内部部分集合の"具体化した複製"への参照
    2. いくつか、あるいは全てのmarkupdecl [29]および、PEReference [69]がXML文書の内部部分集合の中で許容される。PEReferenceが外部実体のさらなる拡大をほのめかし、markupdeclが注釈、処理命令と、要素の宣言、属性一覧、実体と記法らも含むことを留意せよ。
  3. 断片主部の、祖先(Ancestor)の情報。
  4. 断片主部の、兄弟(Sibling)の情報。
  5. あらゆる祖先の、兄弟の情報。
  6. あらゆる祖先、あるいは兄弟の、要素コンテクスト(言い換えれば子孫(descendant)の)情報。
  7. 以下に記す物の、属性の情報(属性の名前と値)
    1. あらゆる祖先
    2. 断片主部の、あらゆる兄弟
    3. あらゆる祖先の、あらゆる兄弟
    4. あらゆる祖先、あるいは兄弟の、あらゆる子孫
  8. ExternalID [75]を明確にすることによる、元/親文書への参照。
  9. ExternalID [75]を明確にすることによる、元/親文書の中の断片主部への参照

上記の一覧を受け、下記の項目が断片の正式な(妥当性を調べる)構文解析に作用する。すなわち、

  • 外部部分集合
  • 内部部分集合
  • 断片主部(より前方)の兄弟

正式な構文解析に作用することができないのに、以下の項目は基本事項で、構造上のXML構文解析木の一部であると通常は考えられている。

  • 祖先
  • (より前方の)祖先の兄弟
  • 断片主部とその祖先の後方の兄弟
  • 祖先と兄弟の子孫
  • 属性

不可欠な基本事項を通常は考慮しないのに、下記の構造上のXML構文解析木が、親文書を処理するXMLプロセッサによって計算、または理解される情報の一部を明確に定義可能である。

  • 親文書のXML宣言情報。XML文書となる断片パッケージを定義済みであることに留意せよ。すなわち、断片パッケージは必要に応じてそれぞれのXMLDeclのような情報を含むだろうから、fci自身はその情報を含む必要がない。
  • 親文書への参照。
  • あるがままの断片主部への参照。

断片コンテクスト設計の記法

断片コンテクスト設計の要旨

前節では断片コンテクストで有効な情報の論理的集合を定めた。今節では断片コンテクスト設計の詳細を表す記法について記述する。全ての情報は任意でよい。特定の断片コンテクスト設計にどの程度の情報を含ませるかは送信側と受信側次第であり、どのように定めるかはこの勧告の範囲外である。

さらに、特定の断片コンテクスト設計に何を含ませるかはこの仕様書の範囲外である。目標となるアプリケーションが持つ知識が、fcsのために適切な水準を定めやすくする。例えば、目標となるアプリケーションが断片を表示するためにカスケーディングスタイルシート(CSS)を用いるユーザエージェントである場合、次の情報がCSSセレクタ機能の現在の水準を与えるに必要十分である。すなわち、断片主部の前方の兄弟、断片主部の全ての祖先、それら祖先個々の前方の兄弟、それら兄弟と祖先の全てが持つ全ての属性。
与えられた断片コンテクスト設計は、前節で述べた断片コンテクスト情報の完全な一式を指定できなければならないわけではない。具体的には、XML 1.0構文の宣言はあるXMLインスタンス中に埋め込み難いので、この勧告によって定められた断片コンテクスト設計記法の仕様では、FCS中の内部部分集合のインライン包含(inline inclusion)を認めない。内部部分集合情報は、内部部分集合の"具体化した複製"への参照を通してのみ、FCSへ含まれる。いったん宣言をインスタンス化する文法を定義すればインライン内部部分集合情報がずっと実現可能になるかもしれないし、将来の断片交換の仕様書で検討されるかもしれない。

使用される構文はXMLそのものである。特に、断片コンテクスト設計(fcs)は、5つまでの属性を許容し、(属性付きかもしれない)他の要素の部分木を含む単一のルートXML要素として記載される。

ルート要素(ならびに、断片主部の代替物として与えられる要素)は、この勧告によって定められた固有の名前空間である断片交換名前空間(Fragment Interchange namespace)によってもたらされ、要素に含まれた部分木は、この断片の元となる文書の名前空間によってもたらされる。今節での解説の都合上、以下の名前空間宣言が有効であるとする。すなわち、

xmlns:f="http://www.w3.org/2001/02/xml-fragment"
xmlns="http://www.oasis-open.org/docbook/DocbookSchema"

この例中のfは、断片交換に関連する構成物のための、この勧告で定められた断片交換名前空間を参照する局所接頭辞であり、あるがままの断片主部の先頭にある既定名前空間は、実際には親文書の中にある。

fcsのための単一のルート要素の要素型は、f:fcs(断片交換名前空間にひも付けられた名前空間接頭辞であればfでなくともよい)となるべきである。ルート要素は5つまでの属性を許容し、その属性値はURI参照[RFC 2396]となるべきである。属性の名称とその値の意味は以下のとおり。

extref
外部部分集合へのURI参照
intref
内部部分集合へのURI参照
parentref
親文書へのURI参照
sourcelocn
親文書の中にあるあるがままの断片主部へのURI参照

f:fcs要素の内容は、親文書の名前空間に属する(場合によっては属性値の割り当てのある)要素の部分木であるべきである。 この部分木は、親文書の中にある(関連する)コンテクストのように、祖先要素と兄弟要素と属性についての様々な情報を含む断片主部のために、全ての構造上のコンテキストを提供するべきである。 fcs:f要素の中では、データ符号のない(複雑な内容)ものも許容される。 特別な空要素f:fragbodyは、特定のコンテクストの中にある断片主部の場所を指し示すために用いられるべきであり、以下のような意味を持つ一つの重要な属性を持つ。すなわち、

fragbodyref
断片主部へのURI参照[RFC 2396]

例えば、book要素の中の最初のpart要素の中の最初のchapter要素の中の2番目のsect1要素の中の、(orderedlist要素上のnumeration属性によりアラビア(arabic)数字として列挙されることを表した)orderedlist要素のlistitem要素たちの2番目と3番目から構成されるような断片主部を考える。外部部分集合("DTD"ともいう)がOASIS Openウェブサーバ上のファイルDocbook.dtdの中にあると仮定すると、親文書はAcmeウェブサーバ上にあるmybook.xmlにあり、fcsの一部として与えられる内部部分集合を必要としない。 その時、断片主部のためのfcsは以下のように見えるだろう。すなわち、

<f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
       extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
       parentref="http://www.acme.com/~me/mydocs/mybook.xml"
       xmlns="http://www.oasis-open.org/docbook/DocbookSchema">
  <book>
    <part>
      <chapter>
        <sect1/>
        <sect1>
          <orderedlist numeration="arabic">
            <listitem/>
            <f:fragbody/>
          </orderedlist>
        </sect1>
      </chapter>
    </part>
  </book>
</f:fcs>

parentref属性とされているhttp://www.acme.com/~me/mydocs/mybook.xmlがアクセス不能であるため、原本のコンテクストが不明ですが、http://arbre.is.s.u-tokyo.ac.jp/~kinaba/seminars/xml/8/8.txtで元のコンテクストと思われる内容を確認可能です。

本則記法の説明

前節の例で用いられたfcs要素のための本則な記法は次のようなものである。その中で、次に挙げる用語、NCNameAttValueEqSAttributeSTagETagEmptyElemTagCharDataReferenceCDSectPICommentprolog、そしてMiscについては、XML 1.0勧告[XML 1.0]かXML名前空間勧告[XML Namespaces]のどちらかで定義されている。

断片コンテクスト設計要素(Fragment Context Specification Element)

[1] FCSelement ::= FCSstag S? FCSelementContent S? FCSetag
[2] FCSstag ::= '<' NCName ':fcs' ((S 'extref' Eq AttValue) | (S 'intref' Eq AttValue) | (S 'parentref' Eq AttValue) | (S 'sourcelocn' Eq AttValue) | (S Attribute))* S? '>' [制約事項: FCSの制約: 断片の名前空間]
[3] FCSelementContent ::= STag FCScontent ETag | FCSfragbody [制約事項: FCSの制約: 厳密に一つのFragbody]
[4] FCSfragbody ::= '<' NCName ':fragbody' ((S 'fragbodyref' Eq AttValue) | (S Attribute))* S? '/>' [制約事項: FCSの制約: 同一の名前空間接頭辞]
[5] FCSetag ::= '</' NCName ':fcs' S? '>'
[6] FCScontent ::= (FCSelementContent | CharData | Reference | CDSect | PI | Comment)*
制約事項: FCSの制約: 断片の名前空間
NCNameとして表されるFCSstag(とFCSetag)用の名前空間接頭辞は、FCS要素の親のどこかで宣言済みでなければならず、かつこの勧告で定められた断片交換名前空間URIに関連付けられねばならない。
制約事項: FCSの制約: 厳密に一つのFragbody
fcsには厳密に一つのfragbody(FCSfragbody)要素が存在しなければならない。
制約事項: FCSの制約: 同一の名前空間接頭辞
FCSfragbody用の名前空間接頭辞(NCName)はFCSstag用のものと同一でなければならない。

[定義: 断片交換名前空間(fragment Interchange namespace)は次のURIと関連付けられる。すなわち、http://www.w3.org/2001/02/xml-fragment.]

In the productions for FCSstag and FCSfragbody, there can be any number of other attribute assignments, all of which are ignored by the fragment context specification processor. Per XML 1.0 compliance, there can be at most one assignment to any given attribute including the specifically mentioned attributes. (Since there is no “and” connector in EBNF, this restriction is difficult to show directly in the EBNF, hence this restriction in prose; however, this prose restriction is normative.)

In the production for FCScontent, the fragment processor can optionally expand any References that it can expand. Then all CDSects, PIs, Comments, remaining References, and CharData (including whitespace, S) are ignored by the FCS processor.

Note
If a Reference in FCScontent is expanded and the expansion includes element structure, that element structure is considered part of the fcs as it would if it had been included originally in its expanded form in the fcs. However, since expansion of any Reference in FCScontent is optional on the part of the fragment context specification processor, any sender for which such expansion is important should do the expansion when creating the fragment package.

Fragment Context Specification

[7] FCS ::= prolog FCSelement Misc* [Constraint: FCS Constraint: Well-formed, namespace complete]
Constraint: FCS Constraint: Well-formed, namespace complete
A fragment context specification shall constitute a well-formed document conforming to the “Extensible Markup Language (XML) 1.0” ([XML 1.0]) and “Namespaces in XML” ([XML Namespaces]) Recommendations. In particular, if there are entity references in the fcs, the fcs document must comply with the Entity declared well-formedness constraint per the “Extensible Markup Language (XML) 1.0” ([XML 1.0]) Recommendation. (Appropriate declarations would appear in the internal subset of the fcs document.) Furthermore, for any use of namespaces, the fcs document must comply with the Namespace declared namespace constraint per the “Namespaces in XML” ([XML Namespaces]) Recommendation.
Note
Generally, a fragment context specification document would be the well-formed document consisting simply of the f:fcs element (and its contents) with no prolog. However, a prolog is always allowable and might be necessary when some declarations are required to satisfy the Entity declared well-formedness constraint.
Note
Since all of the components in prolog are optional, an FCSelement by itself is an allowable fragment context specification, and this Recommendation does not preclude some packaging scheme from combining an FCSelement along with a fragment body as shown in some of the examples in B Packaging and interchanging fragments and C Examples.

断片コンテクスト設計の意味

ある断片コンテクスト設計の例

The parent Docbook book document

The fragment body

The fragment context specification document

一致

参考文献

規範的参考文献

その他の参考文献

断片のパッケージングと交換(参考)

例(参考)

One element of a transaction record as a fragment

Use of external entities and MIME packaging

Indexes into a large document

構成の原則(参考)

謝辞(参考)

前の草稿からの変更点(参考)

Changes between the March 3 and April 2 WD

Changes between the April 2 and June 19 WD

Changes between the June 19 WD and the CR