Namespaces overview (LINQ to XML)
This article introduces XML names, XML namespaces, XML namespace prefixes, and the XName and XNamespace classes.
Another aspect of XML names is XML namespace prefixes, which cause most of the complexity of XML names. These prefixes enable you to create a shortcut for an XML namespace, which makes the XML document more concise and understandable. However, the meaning of an XML prefix depends on context, which adds complexity. For example, the XML prefix aw could be associated with one XML namespace in part of an XML tree, and with a different namespace in another part.
One of the advantages of using LINQ to XML with C# is that you don’t have to use XML prefixes. When LINQ to XML loads or parses an XML document, each XML prefix is resolved to its corresponding XML namespace. After that, when you work with a document that uses namespaces, you almost always access the namespaces through the namespace URI, and not through the namespace prefix. When developers work with XML names in LINQ to XML they always work with a fully-qualified XML name (that is, an XML namespace and a local name). However, LINQ to XML does allow you to work with and control namespace prefixes as needed.
When using LINQ to XML with Visual Basic and XML literals, you must use namespace prefixes when working with documents in namespaces.
In LINQ to XML, the class that represents XML names is XName. XML names appear frequently throughout the LINQ to XML API, and wherever an XML name is required, you will find an XName parameter. However, you rarely work directly with an XName. XName contains an implicit conversion from string.
For more information, see XNamespace and XName.
XML пространства имен
Пространства имен позволяют избежать конфликта имен XML элементов.
Конфликты имен
В XML имена элементов определяет разработчик. Часто это становится причиной конфликта имен при попытке одновременного использования нескольких XML документов от разных XML приложений.
Следующий код XML содержит информацию о HTML таблице:
Следующий код XML содержит информацию о столе (предмет мебели), который по англ. тоже table:
Если эти два фрагмента кода XML будут сведены вместе, то возникнет конфликт имен. Так как оба документа содержат элемент , хотя и с разным контентом и значением.
Пользователь или XML приложение не будут знать, каким образом обрабатывать эти различия.
Разрешение конфликта имен при помощи префикса
В XML избежать конфликта имен можно при помощи префикса имени элемента.
Следующий код XML содержит информацию о таблице HTML и о столе:
В этом примере не будет конфликта имен, так как два элемента имеют разные имена.
Пространства имен XML – Атрибут xmlns
При использовании в XML префиксов необходимо определить, так называемое, пространство имен префикса.
Пространство имен определяется благодаря атрибуту xmlns в начальном теге элемента.
В данном примере, атрибут xmlns в теге определяет префиксам h: и f: квалифицирующее пространство имен.
Когда пространство имен определено для какого-то элемента, то все его дочерние элементы с тем же префиксом ассоциируются с его пространством имен.
Пространства имен могут декларироваться либо непосредственно в самом элементе, либо в корневом элементе XML документа:
Замечание: URI пространства имен не используется парсером для получения какой-либо информации. Цель всего этого состоит в том, чтобы дать пространству имен уникальное имя. Тем не менее, часто компании используют пространство имен, как указатель на веб-страницу с информацией об этом пространстве имен.
Унифицированный идентификатор ресурса (URI)
Унифицированный идентификатор ресурса (URI) это символьная строка, идентифицирующая интернет-ресурс.
В наиболее общей форме URI является единым указателем ресурса (URL), который идентифицирует доменный адрес в интернете. Другой, более частный вид URI — единообразное имя ресурса (URN).
В наших примерах мы будем использовать только URL.
Пространства имен по умолчанию
Определение пространства имен по умолчанию позволяет избежать использования префиксов во всех дочерних элементах. Такое определение имеет следующий синтаксис:
Следующий код XML содержит информацию о таблице HTML:
Следующий код XML содержит информацию о предмете мебели — столе:
Реальное использование пространства имен
XSLT — это XML язык, который может использоваться для преобразования документов XML в другие форматы, например, HTML.
Управление пространствами имен в XML-документе
Пространства имен XML связывают имена элементов и атрибутов в XML-документе с пользовательскими и стандартными URI. Для создания этих связей определяются префиксы для URI пространства имен, с помощью которых затем квалифицируются имена элементов и атрибутов в XML-данных. Пространства имен предотвращают конфликты имен элементов и атрибутов, а также позволяют обрабатывать и проверять элементы и атрибуты с одним и тем же именем.
Объявление пространств имен
Пространство имен для элемента объявляется с помощью атрибута xmlns: :
где — это префикс пространства имен, а — это URI, который определяет это пространство имен. После объявления префикса его можно использовать для уточнения имен элементов и атрибутов в XML-документе и связывания их с URI-кодом пространства имен. Так как этот префикс пространства имен используется во всем документе, он должен быть коротким.
Область видимости объявления
Пространство имен можно использовать только после его объявления, однако это не значит, что объявление пространства имен должно располагаться в самом начале XML-документа.
Если в XML-документе используются несколько пространств имен, можно определить одно из них как пространство по умолчанию, чтобы упростить чтение документа. Пространство имен по умолчанию объявляется в корневом элементе и применяется ко всем элементам в документе, которые не квалифицированы. Пространства имен по умолчанию применяются только к элементам и не применяются к атрибутам.
Для использования пространства имен по умолчанию не указывайте префикс и двоеточие в объявлении элемента:
Управление пространствами имен
В классе XmlNamespaceManager хранится коллекция URI пространств имен и их префиксов. С его помощью можно искать, добавлять и удалять пространства имен из этой коллекции. В некоторых контекстах этот класс необходим для повышения производительности обработки XML. Например, класс XsltContext используется классом XmlNamespaceManager для обеспечения поддержки XPath.
Диспетчер пространств имен не выполняет проверку пространств имен, так как предполагается, что префиксы и пространства имен уже проверены и соответствуют спецификации W3C для пространств имен.
Интерфейс LINQ to XML в C# и Visual Basic использует XmlNamespaceManager для управления пространствами имен. Дополнительные сведения об управлении пространствами имен в случае использования LINQ to XML см. в документации по LINQ, в разделах Работа с пространствами имен XML (C#) и Работа с пространствами имен XML (Visual Basic).
Вот некоторые из задач по управлению и подстановке, которые можно выполнить с помощью класса XmlNamespaceManager. Дополнительные сведения и примеры см. в разделах справочника, посвященных каждому методу или свойству.
Про xmlns. Часть первая
 | /cc1.gif) |
/cc3.gif) | /cc2.gif) |
Атрибут version является обязательным, равно как и объявление XSL-неймспейса xmlns:xsl="http://www.w3.org/1999/XSL/Transform" (иначе было бы неясно, где в шаблоне сам XSL-код). А вот зачем нам нужна запись xmlns="http://www.w3.org/1999/xhtml", не очень понятно.
Для начала уясним, что вообще делают эти конструкции, начинающиеся с xmlns. У всесильного W3C на эту тему тоже есть свой документ, озаглавленный «Неймспейсы в XML». Почитав его (перед сном это делать не рекомендуется), мы узнаем, что основной причиной возникновения неймспейсов явилась необходимость отличать обладающие одним и тем же именем, но имеющие разный смысл и предназначение, относящиеся к разным словарям разметки.
Хорошим примером такого разделения может служить как раз милый нашему сердцу XSL. Скажем, элемент имеет неймспейс xsl и является управляющим XSL-кодом, тогда как элемент
неймспейса не имеет и просто отправляется на вывод, несмотря на то что имя у него тоже text.
Чтобы использовать какой-то неймспейс в своем XML (а XSL есть XML), его надо сначала объявить. Продолжая изучать вышеозначенный документ, мы обнаруживаем, что существуют два способа объявления неймспейсов: с префиксом и без префикса.
Форма с префиксом имеет вид:
Здесь префикс — это некоторое внутреннее имя нашего мы можем использовать любой префикс, какой нам нравится. А вот URI — это такая штука, которая фиксируется раз и навсегда, чтобы при виде этого URI все понимали, какой словарь разметки он представляет. Скажем, написал кто-то на заборе http://www.w3.org/1999/XSL/Transform, и каждому ясно — да это же URI XSL-я! Понятно, что при таком подходе все URI должны быть уникальны.
Следует также понимать, что не «ходят» в интернет, чтобы по этому адресу чего-то скачать. Это всего лишь уникальный идентификатор. Однако здесь возникает вопрос: а что же он тогда выглядит как адрес в интернете? Почему вместо http://www.w3.org/1999/XSL/Transform не писать, например, «у-вас-ус-отклеился»? Ответ прост: когда-то условились, что по этому адресу URI в интернете должна висеть маленькая страничка, в двух словах рассказывающая, что это за URI и какой цели служит. И страничка эта предназначена для человека, а не для машины.
Итак, объявив неймспейс с префиксом, мы теперь можем его использовать — писать элементы, имеющие этот неймспейс. Как это делать, читатель наверняка знает:
Но все привыкли использовать xsl — это коротко и удобно.
Переходим к неймспейсу без префикса. Он имеет вид:
Эта конструкция объявляет неймспейс по умолчанию. Он нужен в ситуации, когда при написании элемента мы не указываем префикс, а пишем сразу имя элемента —
А что если неймспейс по умолчанию не объявлен и у элемента нет префикса? Такую ситуацию вэтрицэшники тоже регламентируют: тогда элемент получит неймспейс, не имеющий значения, который называется null.
Следовательно, запись xmlns="http://www.w3.org/1999/xhtml" в начале XSL-шаблона нужна для того, чтобы сообщить XSL-процессору (трансформатору), что все элементы, не имеющие префикса, относятся к этому неймспейсу XHTML-документов. А что это дает? Самое смешное, что ничего особенного.
Все, что произойдет, — это копирование указанного неймспейса в выходной HTML. То есть такой XSL-шаблон:
Итак, берусь утверждать, что при выводе HTML ощутимой пользы от этого xmlns="http://www.w3.org/1999/xhtml" нет. А есть ли вред? Оказывается, небольшой есть — от неаккуратного использования.
Трансформаторы обязаны копировать xmlns в выходной HTML по XSL-спецификации. Дело в том, что трансформатор может генерировать не только HTML, но и произвольный XML (который может быть подвергнут дальнейшей машинной обработке), и в нем нужно сообщить, какому неймспейсу принадлежат элементы, не имеющие префикса. Причем в этом месте действуют определенные правила. В частности, запись:
говорит, что текущий элемент и все его потомки, не имеющие префикса, относятся к неймспейсу http://www.w3.org/1999/xhtml. Это важно. Именно из-за этого в HTML регулярно вылезают эти записи xmlns="http://www.w3.org/1999/xhtml".
Разберемся на примере. Представим, что у нас есть два XSL-шаблона, причем один импортирует другой.
Импортируемый шаблон import.xsl:
Результатом выполнения главного шаблона будет:
Почему посреди нашего HTML вылезли эти xmlns="http://www.w3.org/1999/xhtml", да еще три раза?
Рассмотрим обратную ситуацию, когда в главном шаблоне есть xmlns="http://www.w3.org/1999/xhtml", а в импортируемом — нет. Тогда на выходе мы получим другой сюрприз:
Элемент и все его потомки законно получают XHTML-неймспейс. Но у абзацев-то он null (ибо в их файле import.xsl xmlns не указан), поэтому абзацы бунтуют и говорят нам: «Идите к черту. Не хотим наследовать ваш XHTML. У нас свой неймспейс null». Это выражается в записи xmlns="" у каждого абзаца, которая как раз и означает, что неймспейс этого элемента null.
Вывод: надо или во всех XSL-файлах объявлять неймспейс по умолчанию, или во всех не объявлять. Лично я везде не объявляю — меньше суеты в коде.
В следующей части мы подробнее разберемся в неймспейсах с префиксом.
dev64
Programming
XML namespaces
Галерея
Оглавление
В работе приходится много сталкиваться с XML. Возник вопрос про XML namespaces (пространства имен по-русски). Я решил написать небольшую статью.
Однако поискал в интернете и нашел совершенно замечательное готовое описание: http://www.w3schools.com/xml/xml_namespaces.asp. Я его перевёл и слегка адаптировал. Если хочется посмотреть оригинал давите либо на ссылку, либо на баннер w3schools.com выше.
Обычный XML выглядит примерно так:
Во многих случаях простого XML достаточно. Например, SOAP-сообщения выглядят значительно сложнее, не смотря на то, что они тоже XML.
(Пример взят: http://www.soapuser.com/basics3.html)
Все дело в том, что в SOAP применяются XML namespace-ы. XML namespace-ы напоминают C++ namespace-ы. В C++ перед именем класса или переменной указывается имя namespace и двойные двоеточия.
В XML применяется prefix:имя_тега.
С применением namespace-ов можно хранить таблицы с данными разных типов:
xmlns аттрибут
Так как namespace-ов может быть много, простых однобуквенных названий namespace-ов может оказаться мало. Чтобы сделать возможным определение действительно уникальных имен namespace-ов вместо имени namespace в тегах применяют короткий префикс. Префикс определяют с помощью аттрибута xmlns в стартовом теге XML-элемента. Конструкция называется namespace declaration и имеет следующий синтаксис.
В примере выше для тега table введены префиксы f: и h: определяющие namespace. Namespace может описываться как в самом теге, для которого он применяется, так и в корневом (root) элементе XML.
В приведенном примере в корневом элементе описаны два namespace, применяемые ниже для тегов table.
URI, указываемое в определении namespace никак не используется парсерами для получения какой либо информации. Это просто уникальная строчка. Назначение URI — просто присвоить namespace уникальное имя. Однако, часто разработчкик используют namespace как ссылку на веб страницу с описанием namespace.
К примеру посмотрите: http://www.w3.org/TR/html4/.
Default Namespaces
Описание «default namespace» для элемента избавляет нас от необходимости использовать префиксы во всех дочерних элеменах. Определение «default namespace» подчиняется следующему синтаксису:
Например нижеприведенная таблица содержит HTML:
А следующий пример несёт информацию про мебель (table = стол в переводе с английского 🙂
Реальные применения namespace
Кроме SOAP, namespace применяются в XSLT. XSLT это XML язык, который может быть использован для описания преобразований XML документов в другие форматы, такие как HTML.
В нижеприведенном XSLT примере, большинство тегов — HTML теги. Теги, не относящиеся к HTML имеют префикс xsl, определенный как
Краткие итоги