Новые возможности в System.Xml
Следующие возможности System.Xml являются новыми для .NET Framework: методы XmlConvert для поддержки W3C четвертого выпуска.
Новые методы 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.
Измененные NullRefenceExceptions в классах, связанных с XML
Класс XslCompiledTransform мог вызывать NullReferenceException при загрузке таблицы стилей.
XmlNode.InnerText мог вызывать NullReferenceException.
Класс XmlValidatingReader мог вызывать NullReferenceException, если некоторые аргументы его конструктора были NULL.
Это поведение изменено для вызова более полезных исключений и упрощения отладки кода.
XmlWriter.Dispose больше не подавляет все исключения
XmlWriter.Dispose раньше подавлял все исключения (включая исключения, которые не должны регистрироваться, например OutOfMemoryException).XmlWriter.Dispose изменен для вызова полезных исключений.
Схемы-хамелеоны теперь клонируются правильно, если они включены несколькими схемами
Схемы, не имеющие целевого пространства имен (называемые также схемами-хамелеонами, раньше включавшими в схему общие типы) принимают целевое пространство имен импортируемой схемы, если они включены в другой XSD.
Если две схемы были в XmlSchemaSet и обе схемы включали схему-хамелеон, схема-хамелеон не клонировалась правильно в обе схемы.Это влияло на проверку XML.Неверная проверка могла привести к повреждению данных.
Теперь клонирование работает должным образом.
XsdValidatingReader.MoveToNextAttribute теперь правильно работает после вызова MoveToAttribute(Int32)
Ошибка в XsdValidatingReader.MoveToAttribute(Int32) вызывала сбой MoveToNextAttribute, поскольку текущий индекс атрибутов никогда не обновлялся.Это не давало возможности полиморфизму работать с различными подклассами XsdReader.
XsdValidatingReader.MoveToNextAttribute теперь будет правильно работать после вызова MoveToAttribute(Int32).
XmlReader.ReadContentAs больше не игнорируется при передаче в IXmlNamespaceResolver
Метод XmlReader.ReadContentAs, который принимает IXmlNamespaceResolver, теперь будет использовать параметр IXmlNamespaceResolver при разрешении пространства имен.До этого параметр IXmlNamespaceResolver пропускался и при разрешении пространств имен использовался XmlReader.
Функция XSLT function-available теперь работает, даже если проверяемая функция никогда не вызывается
Функция function-available используется для определения, доступна ли для использования функция с определенным именем.Раньше, если функция не вызывалась в XSLT, функция function-available всегда возвращала false, даже если функция была доступна.Такая же ошибка была исправлена в MSXML3 SP1.
Исправлены ошибки зависимости в XmlSchemaSet
XmlSchemaSet позволяет выполнять компиляцию схем XSD.Эти схемы могут включать другие схемы (A.xsd может включать B.xsd, которая может включать C.xsd).Компиляция любой из этих схем вызывает прохождение графа зависимостей.Прежде, когда схема в наборе изменялась, а зависимая схема повторно компилировалась или обрабатывалась, производился неверный проход графа зависимостей схем, что приводило к созданию несогласованных скомпилированных схем.
XmlReader.Create возвращал средство чтения, которое неверно отбрасывало значащие пробелы
Проверка XML распознает смешанный режим содержимого, содержащий текст и разметку XML.В смешанном режиме все пробелы являются значащими, и о них должно сообщаться.Раньше XsdValidatingReader сообщал о значащем пробеле как о незначащем.
Бывшее поведение могло приводить к потере данных при загрузке данных в XmlDocument или в XDocument/XElement, который по умолчанию отсекает незначащий пробел.
Оболочка объектов XmlWriter не учитывала NewLineHandling.None
При создании оболочки XmlWriter (XmlWriter, который записывает в другой XmlWriter) с параметром NewLineHandling.None, если использовался метод WriteChars и содержимое включало последовательность «/r/n», вывод содержал последовательность «/r/n/r/n» (повреждение данных).Имеются два общих сценария, на которые влияло такое поведение.
Когда используется существующий XmlWriter, созданный из XmlSerializer, а затем производится оборачивание этого средства записи.Если объект-получатель созданного XML был зависим от пробела (например, веб-служба стороннего разработчика), можно было ожидать непредвиденное поведение.
При использовании XmlWriter для вставки содержимого в существующий XmlDocument или XDocument.Предыдущее поведение не позволяло правильно нормализовать переводы строк в содержимом, добавляемом в документ.
Благодаря этому исправлению NewLineHandling.None имеет правильное поведение для оборачивания средства записи.
В XmlWriter ссылки на сущности были дважды преобразованы в сущность в атрибутах XML
Если пользователь пытался записать сущность в атрибут xmlns, в атрибут xml:lang или атрибут xml:space, используя XmlWriter.WriteEntityRef, сущность дважды проходила преобразование при выводе, что повреждало данные.
XmlWriter w = XmlWriter.Create(Console.Out);
w.WriteDocType("root", null, null, "<!ENTITY e \"ru-ru\">");
w.WriteStartElement("root");
w.WriteStartAttribute("xml", "lang", null);
w.WriteEntityRef("e");
w.WriteEndAttribute();
w.WriteEndElement();
w.Close();
Вывод:
<!DOCTYPE root [<!ENTITY e "ru-ru">]><root xml:lang="&e;" \>
Ожидается:
<!DOCTYPE root [<!ENTITY e "ru-ru">]><root xml:lang="&e;" \>
Теперь нет двойного преобразования в сущность.
XNode.CreateReader возвращает правильный BaseURI
Если объект XmlReader создавался из класса LINQ to XML с помощью CreateReader, средство чтения не возвращало правильный BaseURI, пока хотя бы один раз не вызывался метод Read.В результате код, зависящий от значения BaseURI до первого вызова Read, будет изменен после вызова Read непосредственно из кода или из другого вызова, такого как передача XmlReader другому методу.
Используя XSLT с LINQ to XML, функция XSLT ID теперь возвращает правильное значение
Если объект XmlReader создается из класса LINQ to XML с помощью функции CreateReader и этот XmlReader передается в XSLT, любые экземпляры функции ID в XSLT раньше возвращали NULL.NULL не является допустимым возвращаемым значением для функции ID.Любой код, зависящий от значения ID, равного NULL, должен быть изменен.
DocumentXPathNavigator теперь правильно сообщает локальное имя атрибута x:xmlns
DocumentXPathNavigator раньше возвращал пустую строку для локального имени атрибута x:xmlns.Предыдущее поведение могло привести к повреждению данных и не позволить использование XSLT для создания других XSLT при определенных обстоятельствах.
Локальное имя теперь возвращается правильно, что дает возможность возвращаемым документам или коду XSLT, который создает другие XSLT, использовать x:xmlns.
XsltReader и XmlReader в поддереве не создают повторяющихся объявлений пространства имен в одном элементе XML
При чтении XSLT с помощью XsltReader, если XmlReader помещен в XsltReader, результирующий элемент XML содержал повторяющиеся объявления пространства имен, что является недопустимым XML и могло вызывать проблемы с некоторыми процессорами XML.
Такое предыдущее поведение могло привести к повреждению данных и предотвратить создание допустимого XML из XmlReader.
См. также
Основные понятия
Новые возможности .NET Framework 4
Новые возможности Visual Studio 2010