この規格ページの目次
41
X 4159 : 2005
附属書E(参考)決定的内容モデル
3.2.1 要素内容で示したとおり,要素型宣言中の内容モデルは決定的である必要がある。この要求は,
SGMLとの互換性のために導入する(SGMLでは,決定的内容モデルを"非曖昧"と呼ぶ。)。 SGMLシステ
ムを用いて作成したXMLプロセサは,非決定的内容モデルを誤りとしてもよい。
例えば,内容モデル((b,c) | (b,d))は非決定的となる。これは,最初にbを与えたとき,モデル内のい
ずれのbとマッチするのか,その次の要素を先読みすることなしには,XMLプロセサは知ることができ
ないことによる。この場合は,bの二つの出現は,一つにまとめることができ,モデルは(b,(c | d))とな
る。こうすれば,明らかに最初のbは,内容モデル内の一つの名前とだけマッチする。プロセサは先読み
して,次にくるものを知る必要がない。cもdも受理される。
形式的に示せば次のとおり。Aho,Sethi,and Ullman(附属書AのA.2参考文献の“Aho/Ullman”を参
照。)の3.9のアルゴリズム3.5などの標準的なアルゴリズムを用いて,内容モデルから有限オートマトン
を構成することができる。この種の多くのアルゴリズムでは,正規表現における各々の位置(つまり,正規
表現の構文木における各々の末端ノード)に対して,follow setを構成する。ある位置に対するfollow setに
おいて,複数の位置が同じ要素型名でラベル付けされていれば,その内容モデルは誤りとなり,誤りとし
て報告してもよい。
すべての非決定的内容モデルを等価な決定的内容モデルに変換することはできないが,多くの非決定的
内容モデルを変換するアルゴリズムが存在する。Bruggemann-Klein 1991(附属書AのA.2参考文献の
“Bruggemann-Klein”を参照。)を参照のこと。
――――― [JIS X 4159 pdf 46] ―――――
42
X 4159 : 2005
附属書F(参考)文字符号化の自動検出
XMLの符号化宣言は,各実体の内部ラベルとして機能し,どの文字符号化を使用するかを示す。しかし,
XMLプロセサは内部ラベルを読む前にどの文字符号化を使われているかを知る必要があり,これが,内部
ラベルが示そうとしていることに他ならない。一般的には,これは絶望的な状態となる。しかし,XML
においては,完全には絶望的ではない。これは,一般的な場合に対する次の二つの制限を,XMLが加えて
いることによる。一つの制限は,どの実装も有限個の文字符号化だけをサポートするものと見なす。他の
一つは,XMLの符号化宣言の位置及び内容を制限して,各実体で使用する文字符号化の自動検出を可能に
する。また,多くの場合に,XMLのデータストリームに加え,他の情報が利用できる。ここでは,XML
の実体がプロセサに渡されるとき,(外部)情報を伴うかどうかによって,二つの場合に分ける。まず最初
の場合を示す。
F.1 外部の符号化情報がない場合の検出
外部の符号化情報をともなわず,UTF-8又はUTF-16符号化ではないXML実体は,最初の文字列を'<・xml'
とするXML符号化宣言で始めなければならないので,どの適合したプロセサも,入力にある2オクテッ
ト又は4オクテットを調べれば,次のどの場合があてはまるかを検出できる。このリストを読む際には,
UCS-4の'<'が"#x0000003C",'・'が"#x0000003F",及びUTF-16のデータストリームの必要とする“印”(し
るし)が"#xFEFF"ということを知っておくと役立つ。 ##記法は任意のバイト値を表すが,連続する二つの
## が両方とも00であることはないという例外がある。
附属書F表 1 “印”(しるし)がある場合
00 00 FE FF UCS-4,big-endianマシン (1234 order)
FF FE 00 00 UCS-4,little-endianマシン(4321 order)
00 00 FF FE UCS-4,普通でないオクテット順(2143)
FE FF 00 00 UCS-4,普通でないオクテット順(3412)
FE FF ## ## UTF-16,big-endian
FF FE ## ## UTF-16,little-endian
EF BB BF UTF-8
附属書F表 2 “印”(しるし)がない場合
00 00 00 3
C UCS-4。又は,他の符号化であって,32ビットのコード単位をもち,ASCII 文字をASCII
3C 00 00 コード値として符号化するもの。それぞれ,big-endian (1234),little-endian (4321),
二つの普通ではないオクテット順 (2143と 3412)とする。 UCS-4とその他の32ビッ
00
トの符号化とのどちらであるかを決定するためには,符号化宣言を読み込まなくてはな
らない。
00 00 3C
00
――――― [JIS X 4159 pdf 47] ―――――
43
X 4159 : 2005
00 3C 00
00
UTF-16BEかbig-endianの ISO-10646-UCS-2。又は,その他の16ビットのコード単
00 3C 00 位をもつbig-endianの符号化方式であって,ASCII文字をASCIIコード値として符号
3F 化するもの。(これらのうちどの符号化方式であるかを判定するためには,符号化宣言を
読み込まなくてはならない。)
UTF-16LEかlittle-endianの ISO-10646-UCS-2。又は,その他の16ビットのコード
3C 00 3F 単位をもつlittle-endianの符号化方式であって,ASCII文字をASCIIコード値として符
00 号化するもの。(これらのうちどの符号化方式であるかを判定するためには,符号化宣言
を読み込まなくてはならない。)
UTF-8,ISO 646,ASCII,ISO 8859の各パート,Shift-JIS,EUC,並びに任意の他の
7ビット,8ビット又は混在幅の符号化方式であって,ASCII文字を通常の位置,幅及び
3C 3F 78 値とすることを保証するもの。これらのどれが使われているかを検出するためには,実
6D 際の符号化宣言を読み込まなければならない。しかし,これらすべての符号化方式は,
関係するASCII文字に対して同じビットパターンを使用するので,符号化宣言自体は,
正確に読込むことができる。
4C 6F A7 EBCDIC (又はその変種。どのコードページを使用するかを知るためには,符号化宣言全
94 体を読み込まれなければならない。)
符号化宣言なしのUTF-8。そうでないときには,データストリームに誤ったラベルが付
その他 されている(必要な符号化宣言が欠落している)か,損傷しているか,文書の断片であるか,
何らかの形式に従って埋め込まれている。
備考 これらの場合のうち,符号化を決めるために符号化宣言を読む必要がない場合においても,本
体の4.3.3は,符号化宣言(もし存在するなら)を読み込むことを要求しており,符号化の名前が
実体の実際の符号化とマッチすることを確かめることを要求している。また,符号化を決める
ために符号化宣言を用いる必要が現在はなくても,新しい文字符号化 が発明されることによっ
て符号化宣言を用いることが必要になることもあり得る。
この程度の自動判別でも,XMLの符号化宣言を読み込み,文字符号化の識別子を十分解析できる。識別
子の解析は,類似する各々の符号化の一つ一つを区別するために必要になる(例えば,UTF-8をISO 8859
から区別するため,若しくはISO 8859の各パートを区別するため,又は用いている特定のEBCDICコー
ドページを区別するため。)。
符号化宣言の内容を ASCIIレパートリーにある文字(どのように符号化される場合であっても)に限定し
ているので,どの系統の符号化が使用されているかを検出すれば,プロセサは符号化宣言全体を正確に読
み込むことができる。現実問題として,広く使用されている文字符号化は前述の系統のいずれかにあては
まるので,オペレーティングシステム又は伝送プロトコルが与える外部情報を信頼できないときでも,内
部ラベルで文字符号化をかなり正確に示すことがXML符号化宣言によって可能となる。 ASCIIのコード
値をもつバイトを過度に用いる文字符号化(例えばUTF-7) は,確実に検出できないことがある。
プロセサが文書の符号化を検出しさえすれば,それぞれの場合に対して別の入力ルーチンを呼び出すか,
又は入力する各文字に対し適切な変換関数を呼び出すことによって,適切に動作することができる。
自分自体にラベル付けをするいかなるシステムでも同様だが,ソフトウェアが,符号化宣言を更新せず
に実体の文字集合又は符号化を変えれば,XMLの符号化宣言は機能しない。文字符号化ルーチンの実装者
は,実体のラベル付けに使用する内部及び外部の情報の正確さの保証に注意すべきである。
――――― [JIS X 4159 pdf 48] ―――――
44
X 4159 : 2005
F.2 外部の符号化情報が存在するときの優先順位
2番目の場合は,XMLの実体の他に,符号化についての情報が存在するときである。幾つかのファイル
システム及びネットワークプロトコルでは,その符号化についての情報が存在する。複数の情報が利用で
きるとき,それらの相対的な優先度と,それらが矛盾したときの望ましい処理方法とは,XMLの配送に使
用するより高水準のプロトコルの一部として規定するのがよい。特に,IETF RFC 3023又はその後継RFC
を参照されたい。このRFCはMIMEタイプtext/xmlと application/xmlを定義しており,幾つかの有用な
指示を与えている。相互運用性のため,次の規則を推奨する。
a) MLの実体がファイルに存在すれば,“印”(しるし)及び符号化宣言は,(存在すれば)文字符号化を決
定するために使用する。
――――― [JIS X 4159 pdf 49] ―――――
45
X 4159 : 2005
附属書G(参考)W3C XML作業グループ
この規格の原勧告は,W3C XML作業グループ(WG)が準備し,公開を承認した。WGがこの規格の原勧
告を承認するということは,WGのすべての委員が承認投票を行ったということを必ずしも意味しない。
XML WGの現在の委員及び以前の委員を次に示す。
Jon Bosak,Sun (Chair)
James Clark (Technical Lead)
Tim Bray,Textuality and Netscape (XML Co-editor)
Jean Paoli,Microsoft (XML Co-editor)
C. M. Sperberg-McQueen,U. of Ill. (XML Co-editor)
Dan Connolly,W3C (W3C Liaison)
Paula Angerstein,Texcel
Steve DeRose,INSO
Dave Hollander,HP
Eliot Kimber,ISOGEN
Eve Maler,ArborText
Tom Magliery,NCSA
Murray Maloney,SoftQuad,Grif SA,Muzmo and Veo Systems
村田 真,富士ゼロックス情報システム(株)
Joel Nava,Adobe
Conleth O'Connell,Vignette
Peter Sharpe,SoftQuad
John Tigue,DataChannel
――――― [JIS X 4159 pdf 50] ―――――
次のページ PDF 51
JIS X 4159:2005の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.240 : 情報技術(IT)の応用 > 35.240.30 : 情報,ドキュメンテーション及び出版業務におけるITの応用