完全正規化済み

[46] 完全正規化済み (fully-normalized) とは、XML文書が NFC で、名前や文字データなどの先頭が合成文字や合成文字の文字参照でないことをいいます。

定義

[4] テキストが完全正規化済み (fully-normalized) であるとは、次のいずれか指します >>3。

[7] ある言語における >>5 の「構造」とされる単位のことを関係する構造と呼んでいます。

[9] Charmod に適合する仕様書やそのデータや実装は次のことを要求されています >>8。

[10] テキストは完全正規化済みであるべきです。そうでなくても取り込み正規化済みであるべきです。
[11] 構文定義は完全正規化済みまたは取り込み正規化済みを要求するべきです。 >>5 の構造の境界を正確に定義するべきです。
[12] suspect text は完全正規化済みまたは取り込み正規化済みにしてからでないと normalization-sensitive な操作を適用してはなりませんし、 normalization-sensitive な操作の直後にも同じく正規化しなければなりません。
[13] 完全正規化済みが要求されなくても、著者は構造の先頭に合成文字を使うべきではありません。
[14] 正規化転符号化器を使うべきです。
[15] API は完全正規化済みまたは取り込み正規化済みにする責任をもつのが呼び出し元か呼ばれた先のどちらか定義しなければなりませんし、任意選択とするなら行う方を既定値とするべきです。
[16] 最終的な出力が完全正規化済みまたは取り込み正規化済みであることを要求するべきです。
[17] 仕様書や実装が以上の条件に違反する時は、明記しなければなりません。
[18] 仕様書は完全正規化済みや取り込み正規化済みに関わるセキュリティー上の既知の問題を記載しなければなりません。

[20] この要件に素直に従うとほとんどすべての文字列操作の直後に正規化しなければならず、流石にそんな要求に従っている仕様書も実装もありません。完全正規化済みなる概念自体が W3C のごく一部の仕様書以外ではほとんど無視されています。

[23] XML 1.1 は Charmod のコピペにより同等の「完全正規化済み」を独自に定義しています >>22。

[32] XML 1.1 の XML処理器は利用者に完全正規化済み形かどうか検査する選択肢を提供するべきです >>24。検査しない選択肢は、入力が certified text の時だけ選ぶべきです >>24。

[33] >>32 後半は利用者に対する適合性???

[35] 新しいUnicodeの版の文字など正規化の特性を決定できない文字がある時は、利用者の任意選択により、それによる正規化の崩れを無視して構いません。信頼性やセキュリティーが重要な時はこれを選ぶべきではありません。 >>24

[39] 完全正規化済み形に関する規定は XML 1.1 の変更点として扱われていて、 XML 1.0 には追加されていませんでした。その後、事実上 XML 1.1 を廃止するものとして XML 1.0 5e が出版されましたが、完全正規化済み形の規定は含まれないままでした。

[40] しかし2009年9月になって正誤表 >>38 によって完全正規化済みが「復活」しました。

[41] XML 1.1 の規定とは違って簡潔で、コピペではなく Charmod の CR を参照しています。「Note」なのに SHOULD を含むという不思議な形になっています。

[42] XML の仕様書では Note も normative なようです。

[43] XML 1.1 とは違って関連する構造が何なのか定義されていません。