Это то, что мне всегда трудно понять другим: Почему существуют пространства имен XML? Когда мы должны их использовать, а когда нет? Каковы общие ошибки при работе с пространствами имен в XML?
Также, как они соотносятся с XML-схемами? Должны ли XSD-схемы всегда ассоциироваться с пространством имен?
Они предназначены для одновременного объединения нескольких языков разметки, не беспокоясь о конфликтах имен элементов и атрибутов.
Например, посмотрите на любой бит XSLT-кода, а затем подумайте, что произойдет, если вы не используете пространства имен и пытаетесь написать XSLT, где вывод должен содержать "шаблон", "для каждого", и т.д., элементы. Синтаксические ошибки - вот что.
Я оставлю совет и подводные камни другим, имеющим больше опыта, чем я.
Это почти то же самое, что и вопрос: "Почему мы используем пакеты для Java/С#?":
Самая большая ошибка IMHO - это документы для интерпретации взаимодействия с людьми, например. разработать код для обработки XML Doc. Слишком легко сосредоточиться на буквальном выражении документа, а не на информационном результате анализа документа.
например. следующие узлы
<a xmlns="uri:foo"/>
<foo:a xmlns:foo="uri:foo"/>
<bar:a xmlns:bar="uri:foo"/>
все семантически идентичны, но очень отличаются от наивного глаза.
В первом примере возникает очень распространенная ошибка при разработке XPaths - отсутствует тот факт, что "a" находится в пространстве имен, и//не дает совпадений. (или, что еще хуже, совпадающие узлы в другом пространстве имен!)
Третий пример открывает еще один недостаток в понимании - текст префикса семантически значим. При анализе документов с помощью XPATH я могу объявить любой префикс, который мне нравится для сопоставления, если он совпадает с uri документа.
Почему существуют пространства имен XML?
Потому что, еще в 1997 году, некоторые очень влиятельные люди в W3C хотели их, и не ответили бы. Даже когда это было продемонстрировано, я осмеливаюсь сказать окончательно, что есть более эффективные способы решения "проблемы", о которой они думали, они все же использовали свое влияние, чтобы их желания были записаны в Рекомендацию W3C.
Самый большой битп в обширной мифологии вокруг пространства имен XML - это то, что для них есть технические достоинства. (Это нижестоящий эффект Рекомендации, просто существующей и, таким образом, занимающей пространство мышления - "да, там должна быть (хорошая) причина!" - в отличие от забываемой сноски где-то.)
Большая боль, отсутствие выгоды.
Когда мы должны использовать их, а когда не будем?
Вы не должны использовать их, если сможете это сделать. К сожалению, неустанное продвижение этого устройства BAD [*] заинтересованными сторонами способствовало созданию кластерных функций спецификаций сегодня, из-за чего практически невозможно не столкнуться с пространствами имен XML в какой-то момент. Таким образом, даже если вы избегаете пространства имен XML самостоятельно, вы обнаружите, что на вас нападает пространство имен, со всех сторон, или, что еще хуже, инструменты, которые просто отказываются работать, если вы не кормите их такой грубой.
Каковы общие ошибки при работе с пространствами имен в XML?
Одна очень распространенная ошибка заключается в использовании выражений Xpath с документами, в которых пространство имен было "дефолтом": пространство имен должно быть явным в выражениях. Другая проблема заключается в том, чтобы использовать их "правильно" при построении документов: они создают проблемы из-за тонкого эфира.
Также, как они соотносятся с XML-схемами? Должны ли XSD-схемы всегда ассоциироваться с пространством имен?
Нет никакого необходимого отношения, за исключением того, что спецификация XSD Schema была разработана в то время, когда почти все члены комитета имели бит XML Namespaces в своих зубах. Поэтому они работали так глубоко, как могли. Тем не менее, можно использовать схемы XSD без пространств имен, но это крутой подъемник, как и любой набор инструментов, поддерживающий схемы XSD, предполагает, что вы будете "хотеть" использовать пространства имен.
[*] BAD = Broken As Designed
UPDATE: Старое эссе об этом не-решении проблемы без проблем.
Подумайте о них как о фамилиях для типов элементов. Если у вас есть двое друзей, обоих зовут Боб, и вы говорите об одном из них, кто-то может спросить, о ком вы говорите. Просто сказать "Боб" не очень полезно, поэтому вы говорите "Боб Смит" или "Боб Джонс".
То же самое с типами элементов. Иногда короткого имени недостаточно, потому что разные люди могут выбрать одно и то же имя. Таким образом, вы включаете URI в качестве "фамилии", чтобы различать разные Бобы там.
XML - это суперязык, означающий, что он является основой для любого языка на основе XML (имеет смысл, правильно?). Подумайте о XML как о ручке, которая может писать любое предложение на любом языке. Все зависит от автора, и предпочтительно, чтобы язык был известен читателю.
Пространство имен XML - это, в основном, название языка, как "английский" или "עברית". Я помогаю получателю XML-документа проанализировать его и извлечь информацию внутри.
Скажем, что у меня есть мебель factory, и у вас есть мебельный магазин. ваше приложение для хранения и приложение подачи полностью не связаны, но когда они обмениваются данными через XML-сообщения, сообщения должны быть понятными и легко анализироваться обеими сторонами
Поэтому обе системы должны знать Схема, которая определяет синтаксис языка и согласованные ограничения. Вспомните схему как словарь и учебник грамматики. Схема - это документ, который должны знать обе системы, о том, кто должен знать код разбора в каждой системе, и который включает объявление пространства имен.
Каждое пространство имен называется URI, в большинстве случаев это расположение документа схемы, который его определяет.
Конечно, не каждому XML-документу требуется пространство имен, особенно если оно не используется для передачи информации в удаленную систему. Например, когда вы сериализуете объекты в XML для сохранения в своей базе данных.
Мы используем пространства имен, потому что люди xeep хотят использовать одни и те же слова, чтобы обозначать разные вещи в их собственном частном idaho. Обычно вы можете определить из контекста, что означает человек. В кадровой базе данных XML - это записи персонала. В базе данных реестра транспортных средств XML - это записи реестра транспортных средств.
Оба сохраняют тег с именем "location", но тег означает разные вещи для каждого и содержит разные поля.
Теперь, это круто: но что, если вам нужно или хотите хранить XML из обеих в одной базе данных? Или, что более интересно, что, если обе базы данных хотят хранить фрагменты XML из какой-либо другой общей базы данных (например, базы данных учетных записей).
пространства имен XML связывают с каждым тегом XML URI, так что у самого имени тега перед ним есть URL-адрес, эта часть имени тега (конечно, фактические документы XML используют сокращенную версию). Тщательно выбирая URI, легко быть уверенным в том, что имена тегов не будут сталкиваться - как будто два тега местоположения были названы совершенно по-другому, поэтому нет путаницы. В качестве бонуса два совершенно разных тега местоположения могут включать материал из базы данных учетных записей и явно указывают, что они говорят об одном и том же.
Вещь, которая делает все это полезной, - XPATH.
С вышесказанным вы можете начать писать выражения XPATH, которые говорят такие вещи, как: найдите мне любые разделы accounts:account overdue в любом месте этого xml. Или: найдите мне какие-либо элементы accounts:warning message в любом месте этого фрагмента XML, где предупреждающее сообщение является дочерним node (как бы глубоким) ни personnel:payment node, ни vehicle:status node.
Это выражение XPATH может быть использовано где-то в документе XSLT, задача которого - преобразовать XML в XHTML или XPDF для отображения.
Какая выгода? Почему? Поскольку вы можете искать файл журнала XML, вытаскивайте все сообщения с просроченными сообщениями везде, где они появляются, не смешивая их с тегами "сообщения", создаваемыми другими системами, конвертируйте их в xhtml и отобразите их жирным красным цветом с помощью тега css: все без написания фрагмента процедурного кода.
Из рекомендация W3...
пространства имен XML предоставляют простой метод для определения имен элементов и атрибутов, используемых в документах расширяемого языка разметки, путем связывания их с пространствами имен, идентифицированными ссылками URI.
Пространства имен используются для устранения неоднозначности имен, которые вы используете в документе. Он также дает возможность привязывать короткое имя к пространству имен, которое затем может использоваться для ссылки на удаленный элемент или атрибут. Само пространство имен относится к местоположению, которое определяет элементы и атрибуты, используемые в документе. Намного больше узнать, но это и есть его сердце. Существует гораздо больше информации здесь.
Например: Пространства имен XML по примеру
По-моему: если вы должны использовать какой-либо формат XML для внешней компании (например), и вам нужно предоставить в документе XML некоторые сведения, имеющие одно и то же имя, вам нужно пространство имен. Пример:
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="Blue"/>
</items>
</header>
</sampleDoc>
и вы хотите объединить некоторые данные в этот документ, который имеет одно и то же имя, но другой смысл (так что значение), вы должны использовать пространство имен:
<sampleDoc>
<header title="Hello world!">
<items>
<item name="Volvo" color="White" my_unique_namespace:color="#FFFFFF"/>
</items>
</header>
</sampleDoc>
Конечно - вы можете изменить имя атрибута. Например, "my_unique_color". Bud в другом документе, снова может быть атрибут с таким же именем. Итак, если у вас есть уникальное пространство имен (например, наш веб-домен), вы всегда можете использовать одинаковые имена элементов и/или атрибутов при любых проблемах.