XML-документы могут использоваться в качестве промежуточного формата данных в трехзвенных системах. Обычно схема взаимодействия между серверами приложений и баз данных зависит от конкретной СУБД и диалекта SQL, используемого для доступа к данным. Если же результаты запроса будут представлены в некотором универсальном текстовом формате, то звено СУБД, как таковое, станет "прозрачным" для приложения. Кроме того, сегодня на рассмотрение W3C предложена спецификация нового языка запросов к базам данных XQL, который в будущем может стать альтернативой SQL.
Информация, содержащаяся в XML-документах, может изменяться, передаваться на машину клиента и обновляться по частям. Разрабатываемые спецификации XLink и Xpointer позволят ссылаться на отдельные элементы документа, c учетом их вложенности и значений атрибутов.
Использование стилевых таблиц (XSL) позволяет обеспечить независимое от конкретного устройства вывода отображение XML- документов.
XML может использоваться в обычных приложениях для хранения и обработки структурированных данных в едином формате.
XML-документ представляет собой обычный текстовый файл, в котором при помощи специальных маркеров создаются элементы данных, последовательность и вложенность которых определяет структуру документа и его содержание. Основным достоинством XML документов является то, что при относительно простом способе создания и обработки (обычный текст может редактироваться любым тестовым процессором и обрабатываться стандартными XML анализаторами), они позволяют создавать структурированную информацию, которую хорошо "понимают" компьютеры.
Пример XML-документа:
<?xml version="1.0" encoding="koi-8"?>
<notepad>
<note id="1" date="12/04/99" time="13:40">
<subject>Важная деловая встреча</subject>
<importance/>
<text>
Надо встретиться с <person id="1625">Иваном Ивановичем</person>,
предварительно позвонив ему по телефону <tel>123-12-12</tel>
</text>
</note>
...
<note id="2" date="12/04/99" time="13:58">
<subject>Позвонить домой</subject>
<text>
<tel>124-13-13</tel>
</text>
</note>
</notepad>
LINQ to XML
Microsoft могла бы ограничиться тем, что предоставила бы нам интерфейс LINQ XML API, который позволял бы лишь выполнять запросы LINQ, и все. К счастью для разработчиков XML, они прошли немного дальше. В дополнение к предоставлению поддержки XML запросов LINQ, Microsoft компенсировала многие недостатки стандартного DOM XML API. После нескольких лет мучений с W3C DOM XML API большинству разработчиков стало ясно, что многие задачи оказывается, не так просты, как должны были быть. Имея дело с небольшими фрагментами XML, используя W3C DOM, всегда приходится создавать целый документ XML, даже когда нужно создать всего несколько элементов. Случалось ли вам строить строки, выглядящие как XML вместо применения DOM API, просто потому что это было проще? Уверен, что да.
Несколько ключевых недостатков W3C DOM XML API были преодолены. Была создана новая модель документов. И в результате появился намного более простой и элегантный метод создания деревьев XML. Непомерно раздутый код с появлением LINQ стал достоянием прошлого. Создание полного дерева XML с помощью единственного оператора стало реальностью, благодаря функциональному конструированию. Функциональное конструирование - термин, используемый для описания возможности создания полной иерархии XML в единственном операторе. Уже одно это заставляет ценить LINQ to XML на вес золота. Конечно, это не стало бы частью LINQ, если бы новый XML API не поддерживал запросы LINQ. Именно для этого было добавлено несколько специфичных для XML операций запросов, реализованных в виде расширяющих методов. Комбинация этих новых XML-специфичных операций со стандартными операциями запросов LINQ to Objects создает мощное элегантное решение для нахождения любых нужных данных в дереве XML. LINQ не только поддерживает все это, но комбинируя запрос с функциональным конструированием, вы можете получить трансформации XML. LINQ to XML чрезвычайно гибок.
Конструирование деревьев XML
При чтении кода первого примера сразу становится ясно, что, глядя на этот код создания дерева XML, очень сложно определить схему XML. После создания документа XML мы должны создать некоторого типа узел XML, такой как элемент, установить его значение и добавить к родительскому элементу. Однако каждый из этих трех шагов должен быть выполнен отдельно с использованием W3C DOM API. Это приводит к неясной схеме и объемному коду. Этот API не предусматривает поддержки создания элемента или любого типа узла в определенном месте дерева XML по отношению к его родителю и его инициализации за одну операцию.
LINQ to XML API не только предоставляет ту же возможность создания дерева XML, что и W3C DOM API, но также предлагает новую технику, называемую функциональным конструированием, для создания дерева XML. Функциональное конструирование позволяет схеме диктовать то, как конструируются объекты XML и инициализируются их значения, и все это - одновременно, в единственном операторе. API достигает этого за счет предоставления конструкторов новых XML-объектов, которые принимают в качестве параметров как отдельные объекты, так и их множества, специфицируя их значения. Тип добавляемого объекта или объектов определяет то, где именно в схеме они располагаются. Общий шаблон выглядит так:
XMLOBJECT о =
new XMLOBJECT(OBJECTNAME,
XML0BJECT1,
XML0BJECT2,
XMLOBJECTN);
На заметку! Приведенный фрагмент является просто псевдокодом, предназначенным для иллюстрации шаблона. Ни один из классов, присутствующих в нем, не существует на самом деле; они лишь представляют некоторый концептуальный абстрактный класс XML.
Если вы добавляете к элементу, реализованному классом XElement, атрибут XML, который реализован классом XAttribute из LINQ to XML, этот атрибут становится атрибутом этого элемента. Например, если в предыдущем псевдокоде XML0BJECT1 добавляется ко вновь созданному XMLOBJECT по имени о, и о является XElement, a XMLOBJECT 1 есть XAttribute, то XMLOBJECT 1 становится атрибутом XElement о.
Если вы добавляете XElement к XElement, то добавляемый XElement становится дочерним элементом того, к которому он добавлен. Поэтому, например, если XMLOBJECT1 - элемент и о — элемент, то XMLOBJECT1 становится дочерним элементом о.
При создании экземпляра объекта XMLOBJECT, как показано в приведенном псевдокоде, мы можем специфицировать его содержимое, указав от 1 до N объектов XMLOBJECT. Как вы узнаете далее в разделе "Создание текста с помощью XText", можно даже специфицировать его содержимое, включающее строку, поскольку строка будет автоматически преобразована для вас в XMLOBJECT.
Все это совершенно логично и составляет суть функционального конструирования
XElement xBookParticipant =
new XElement("BookParticipant",
new XElement("FirstName", "Joe"),
new XElement("LastName", "Rattz"));
Console.WriteLine(xBookParticipant.ToString() ) ;
Обратите внимание, что при конструировании элемента по имени BookParticipant я передал два объекта XElement в качестве его значения, каждый из которых стал его дочерним элементом. Также обратите внимание, что при конструировании элементов FirstName и LastName вместо специфицирования дочерних объектов, как это было сделано при конструировании элемента BookParticipant, я указал просто текстовые значения элементов. И вот результат работы этого кода:
<BookParticipant>
<FirstName>Joe</FirstName>
<LastName>Rattz</LastName> </BookParticipant>
Обратите внимание, насколько проще теперь инициализировать в коде схему XML. Также отметьте, насколько менее многословным стал код, чем код первого примера.
XElement xBookParticipants =
new XElement("BookParticipants",
new XElement ("BookParticipant", "
new XAttribute ("type", "Author'V) ,
new XElement("FirstName", "Joe"),
new XElement("LastName", "Rattz")),
new XElement("BookParticipant",
new XAttribute("type", "Editor"),
new XElement("FirstName", "Ewan"),
new XElement("LastName", "Buckingham")));
Console.WriteLine(xBookParticipants.ToString());
Как видите, здесь намного меньше кода пришлось создать, и намного меньше впоследствии сопровождать. К тому же схему намного легче понять, просто прочитав этот код.
И вот вывод:
<BookParticipants>
<BookParticipant type="Author">
<FirstName>Joe</FirstName>
<LastName>Rattz</LastName>
</BookParticipant>
<BookParticipant type="Editor">
<FirstName>Ewan</FirstName>
<LastName>Buckingham</LastName>
</BookParticipant>
</BookParticipants>
Есть еще одно преимущество нового API, которое наглядно проявляется в результате этого примера. Обратите внимание, что вывод сформатирован так, что он выглядит как дерево XML. Если я выведу дерево XML, оно будет выглядеть следующим образом:
<BookParticipants><BookParticipant type="Author"XFirstName>Joe</FirstName>...
Имена XML
Имена XML часто становятся источником сложности при программировании на XML. Имя XML состоит из пространства имен XML (которое также называется URI-кодом пространства имен XML) и локального имени. Пространство имен XML аналогично пространству имен в программах на основе .NET Framework. Позволяет уникально квалифицировать имена элементов и атрибутов. Это помогает избежать конфликтов имен в разных частях XML-документа. При задании пространства имен XML можно выбрать локальное имя, которое должно быть уникальным только по значению пространства имен.
Другим аспектом имен XML являются префиксы пространств имен XML. Именно префиксы создают основную сложность в работе с именами XML. Эти префиксы позволяют создавать ярлык пространства имен XML, что делает XML-документ более организованным и понятным. Однако, чтобы префиксы XML несли значение, необходимо, чтобы они были соотнесены с определенным контекстом, а это вносит дополнительную сложность. Например, префикс XML aw можно ассоциировать с одним пространством имен XML в одной части XML-дерева и с другим пространством имен XML в другой его части.