System.Xml の新機能
W3C Fourth Edition をサポートする XmlConvert のメソッド (System.Xml) が新しく .NET Framework に追加されました。
XmlConvert の新しいメソッド
XmlConvert クラスの新しいメンバーを使用すると、特定の文字および文字列について、特定の XML トークンまたは有効な XML としての妥当性を検証できます。
public static bool IsNCNameChar(char);
public static bool IsPublicIdChar(char);
public static bool IsStartNCNameChar(char);
public static bool IsWhitespaceChar(char);
public static bool IsXmlChar(char);
public static bool IsXmlSurrogatePair(char, char);
public static string VerifyPublicId(string);
public static string VerifyWhitespace(string);
public static string VerifyXmlChars(string);
Visual Studio 2010 での重要な変更点
以下のセクションでは、System.Xml の大きな変更点について説明します。
XML 関連のクラスで NullRefenceException が変更されました
スタイルシートの読み込み時に XslCompiledTransform クラスが NullReferenceException をスローすることがありました。
XmlNode.InnerText が NullReferenceException をスローすることがありました。
XmlValidatingReader クラスのコンストラクターに null の引数が渡された場合、このクラスが NullReferenceException をスローすることがありました。
これらの動作は、より有用な例外をスローするように、およびコードのデバッグが容易になるように変更されました。
XmlWriter.Dispose ですべての例外が抑制されることがなくなりました
これまで XmlWriter.Dispose は (OutOfMemoryException など通常キャッチされない例外も含め) すべての例外を抑制していましたが、有用な例外をスローするように変更されました。
複数のスキーマにインクルードされるカメレオン スキーマが正しく複製されるようになりました
ターゲット名前空間を持たないスキーマは、他の XSD にインクルードされた時点で、インクルードしたそのスキーマのターゲット名前空間を取得します (このスキーマはカメレオン スキーマとも呼ばれ、以前は 1 つのスキーマに共通の型をインクルードしていました)。
XmlSchemaSet に 2 つのスキーマが存在し、これら両方のスキーマが同じカメレオン スキーマをインクルードした場合、それぞれのスキーマにカメレオン スキーマを正しく複製できませんでした。これにより XML 検証が影響を受けていました。検証が正しく行われず、データが破損する可能性がありました。
現在、複製機能は正常に動作しています。
MoveToAttribute(Int32) 呼び出し後の XsdValidatingReader.MoveToNextAttribute が正常に動作するようになりました
XsdValidatingReader.MoveToAttribute(Int32) のバグにより、現在の属性インデックスが更新されないため MoveToNextAttribute が失敗していました。そのため、XsdReader のさまざまなサブクラスで多態性が機能しませんでした。
MoveToAttribute(Int32) を呼び出した後の XsdValidatingReader.MoveToNextAttribute が正常に動作するようになりました。
XmlReader.ReadContentAs に渡される IXmlNamespaceResolver が無視されなくなりました
IXmlNamespaceResolver を受け取る XmlReader.ReadContentAs メソッドで、IXmlNamespaceResolver パラメーターが名前空間リゾルバーとして使用されるようになりました。従来は、IXmlNamespaceResolver パラメーターは無視され、XmlReader が名前空間リゾルバーに使用されていました。
テストする関数が呼び出されていない場合でも function-available XSLT 関数が機能するようになりました
function-available 関数を使用すると、特定の名前を持つ関数が利用可能かどうかを判断できます。従来は、関数が XSLT 内で呼び出されていない場合、その関数が利用可能であっても、function-available では常に false が返されていました。このエラーは MSXML3 SP1 で修正されました。
XmlSchemaSet の依存関係のバグが修正されました
XmlSchemaSet では XSD スキーマをコンパイルできます。これらのスキーマには他のスキーマをインクルードできます (A.xsd に B.xsd をインクルードし、B.xsd に C.xsd をインクルードできます)。これらのスキーマのいずれかをコンパイルすると、依存グラフがスキャンされます。従来は、セット内のスキーマが変更され、依存スキーマが再コンパイルまたは再処理されると、スキーマの依存グラフが正しくスキャンされず、コンパイルされたスキーマの整合性が失われていました。
XmlReader.Create で返されるリーダーの有意の空白が誤って破棄されていました
XML 検証では、テキストと XML マークアップを含む混合コンテンツ モードを認識します。混合モードでは、空白はすべて有意であり、報告される必要があります。従来、XsdValidatingReader では、有意の空白が意味を持たない空白として報告されていました。
従来の動作では、意味を持たない空白を既定で除去する XmlDocument または XDocument/XElement にデータが読み込まれると、データ損失が発生する可能性がありました。
ラッピング XmlWriter で NewLineHandling.None が優先されていませんでした
ラッピング XmlWriter (他の XmlWriter に書き込む XmlWriter) を作成し、その XmlWriter が NewLineHandling.None を持つように指定した場合、WriteChars メソッドを使用して /r/n を含むコンテンツを出力すると、/r/n/r/n (データ破損) が含まれていました。この動作に影響を受けていた一般的なシナリオは 2 つあります。
XmlSerializer から作成された既存の XmlWriter を使用し、そのライターをラップした場合。生成された XML のコンシューマーで空白が許容されていない場合 (たとえば、サード パーティの Web サービス)、予期しない動作が発生することがありました。
XmlWriter を使用して既存の XmlDocument または XDocument にコンテンツを挿入する場合。従来の動作では、ドキュメントに追加するコンテンツの改行を正しく正規化できませんでした。
この修正により、ラッピング ライターに対して NewLineHandling.None が正しく動作するようになりました。
XmlWriter を使用すると、XML 属性でエンティティ参照のエンティティ変換が 2 回行われていました
ユーザーが XmlWriter.WriteEntityRef を使用して xmlns 属性、xml:lang 属性、または xml:space 属性にエンティティを書き込もうとした場合、エンティティ変換が 2 回行われてから出力されるため、データが破損していました。
XmlWriter w = XmlWriter.Create(Console.Out);
w.WriteDocType("root", null, null, "<!ENTITY e \"en-us\">");
w.WriteStartElement("root");
w.WriteStartAttribute("xml", "lang", null);
w.WriteEntityRef("e");
w.WriteEndAttribute();
w.WriteEndElement();
w.Close();
出力:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
期待される出力:
<!DOCTYPE root [<!ENTITY e "en-us">]><root xml:lang="&e;" \>
現在は、エンティティが 2 回エンティティ変換されることはありません。
XNode.CreateReader で正しい BaseURI が返されるようになりました
CreateReader を使用して LINQ to XML クラスから XmlReader オブジェクトを作成した場合、Read が少なくとも 1 回呼び出されるまで、リーダーから正しい BaseURI が返されませんでした。そのため、最初の Read 呼び出し前の BaseURI の値に依存するコードは、ユーザーのコードから直接または他の呼び出し (XmlReader を他のメソッドに渡すなど) から Read を呼び出した後に変更します。
XSLT と LINQ to XML の使用時に XSLT ID 関数が正しい値を返すようになりました
CreateReader 関数を使用して LINQ to XML クラスから XmlReader を作成した場合、この XmlReader が XSLT に渡されると、XSLT 内の ID 関数のすべてのインスタンスから null が返されていました。null は ID 関数の有効な戻り値ではありません。null 値の ID に基づくコードはすべて変更する必要があります。
DocumentXPathNavigator で x:xmlns 属性のローカル名が正しく報告されるようになりました
DocumentXPathNavigator では、x:xmlns 属性のローカル名に空の文字列が返されていました。従来の動作では、データが破損し、状況によっては XSLT を使用して XSLT を生成できない可能性がありました。
現在はローカル名が正しく返されるようになり、XSLT、他の XSLT を生成するコード、または x:xmlns の使用を返すドキュメントが有効化されています。
サブツリー上の XsltReader および XmlReader で、1 つの XML 要素内に重複する名前空間宣言が作成されなくなりました
XsltReader を使用して XSLT を読み取るときに、XmlReader が XsltReader の上に配置されている場合、結果の XML 要素に重複する名前空間宣言が含まれていました。これは無効な XML であり、一部の XML プロセッサで問題が発生する可能性がありました。
この従来の動作では、データが破損し、XmlReader から有効な XML を作成できない可能性がありました。