Targetnamespace xsd что это
Русские Блоги
Взаимосвязь и роль xmlns, targetNamespace и xsi: schemaLocation в XML и схеме
Пространство имен XML:
В официальном заявлении w3c пространство имен обеспечивает эффект предотвращения конфликтов имен элементов, то есть одно и то же имя элемента представляет разные значения.
Более подробных примеров здесь не приводится, их легко найти в Интернете. Если вы хотите избежать конфликта повторяющихся имен, очевидно, что в документе xml может появиться несколько разных пространств имен.
Синтаксис пространства имен:
xmlns:namespace-prefix=»namespaceURI»
Когда пространство имен определено в начальном теге элемента, все дочерние элементы с одинаковым префиксом будут связаны с одним и тем же пространством имен, а префикс может рассматриваться как псевдоним пространства имен;
xmlns: пространство имен по умолчанию. Если префикса (namespace-prefix) нет, то это пространство имен по умолчанию.Элементы и подэлементы, которые используют это пространство имен, являются элементами пространства имен по умолчанию, если не добавлен другой префикс.
XML Schema：
Схема XML является допустимым строительным блоком для определения документов XML, то есть какие элементы, атрибуты, отношения между элементами, порядок, количество элементов, типы и диапазоны значений элементов или атрибутов и т. Д. Могут присутствовать в документе XML. Способ ограничения документов.
Однако документ xsd (определение схемы XML) также написан на языке XML. Так что он также имеет атрибут xmlns.
Вот простой документ xsd:
targetNamespace：
Этот атрибут объявляет, что элементы, определенные в этом документе схемы XML, принадлежат пространству имен (URI), указанному атрибутом targetNamespace.
Существует явление, что во многих документах xsd вы обнаружите, что значение пространства имен (URI), указанное в xmlns и targetNamespace, одинаково, но связь между ними не является фиксированной. Почему ты так говоришь?
Однако если в средстве IDE, таком как eclipse или idea, в документе xsd с тем же URI, что и в xmlns и targetNamespace (например, в book.xsd, указанном выше), xmlns или targetNamespace изменяются непоследовательно, вы обнаружите, что на IDE есть ссылка в документе xsd из При определении элементов будут сообщаться ошибки. Как показано на следующем рисунке, targetNamespace приведенного выше документа изменено на «http://www.example.org/book_modify».
На первый взгляд они, похоже, снова связаны?
Конечно, пространству имен по умолчанию xmlns и targetNamespace также могут быть присвоены разные значения, и дополнительное пространство имен с префиксом может использоваться для ссылки на элементы в пространстве имен targetNamespace, так что префикс необходимо добавлять при использовании элементов, определенных в targetNamespace. следующее:
Примеры схемы, используемые в XML:
Вот XML-файл, который использует book.xsd для ограничения
В документах xml мы часто видим пространства имен, такие как xmlns: xsi = «http://www.w3.org/2001/XMLSchema-instance», так что же он делает?
Его роль заключается в том, чтобы сообщать анализатору документов xml о проверке документа XML с определенным экземпляром схемы. И URI пространства имен
“ http://www.w3.org/2001/XMLSchema-instance «Является фиксированным значением, этот URI указывает на документ xsd, а значением целевого пространства имен xsd является этот URI. В то же время в xsd определены четыре атрибута, и один из них имеет имя: schemaLocation, которое также находится в документе xml. Часто используется, как в приведенном выше примере
Роль xsi: schemaLocation:
Префикс xsi настроен, но теперь все привыкли к этой официальной привычке.
Его роль заключается в информировании синтаксического анализатора о том, что элементы в пространстве имен, заданном schemaLocation, ограничены схемой xsd. Как и буквальное значение имени атрибута, он определяет местоположение схемы.
Однако, если вы хотите, чтобы схема работала, вам нужно сделать URI xmlns в xml таким же, как URI targetNamespace документа xsd. А в schemaLocation значение namespaceURI должно совпадать с xmlns, то есть targetNamespace файла xsd, чтобы синтаксический анализатор мог точно знать, какой схеме должны следовать элементы в xmlns. Конечно, вы также можете добавить префикс пространства имен после xmlns, и элементы, измененные префиксом, должны соответствовать спецификациям схемы. Например:
TargetNamespace и xmlns без префикса, в чем разница?
В документе схемы xml, если у меня есть как targetNamespace, так и xmlns без префикса.
Какая разница между ними? Мое понимание заключается в том, что если у вас есть xmlns без префикса, все элементы без префикса получат это пространство имен и. путано то же самое касается targetNamespace.
ОТВЕТЫ
Ответ 1
По моему опыту, многие авторы XML Schema считают это «лучшей практикой». так что вы на правильном пути.
В терминах XSD, targetNamespace предписывает часть пространства имен квалифицированного имени компонента схемы, которая включает в себя элементы, атрибуты, группы и группы атрибутов, а также простые и сложные типы. Некоторые из квалифицированных имен, определенных в XSD (элементы и атрибуты), «непосредственно» используются документом экземпляра XML. Другие, например, для типов, можно ссылаться через атрибут xsi: type в экземплярах XML-документов. Остальные (группы, группы атрибутов) используются для облегчения составления схемы (посредством ссылок).
Я также считаю, что (в общем) люди придумывают XSD с двух сторон:
чтобы соответствовать существующему XML. В этом случае, если ваш XML использует пространства имен, для каждого из используемых пространств имен вы получите элемент схемы XSD с соответствующим атрибутом targetNamespace.
Ответ 2
Для тех, кто все еще запутался, рассмотрите эти три xsds. Все они определяют один глобальный тип и одно глобальное определение элемента, которое ссылается на него.
Во-первых, xsd, как тот, который был выше. Он использует префикс ‘xsd’ для пространства имен схемы и пространство имен по умолчанию для targetNamespace:
Теперь тот же xsd, но определяющий и использующий префикс пространства имен для целевого пространства имен:
. и, наконец, версия, которая использует пространство имен по умолчанию вместо «xsd» для пространства имен схемы XML:
Большинство авторов схемы выбирают первый или последний, потому что, если доступно пространство имен по умолчанию, мы могли бы использовать его для чего-то.
Ответ 3
XMLNS
Атрибут xmlns задает пространство имен по умолчанию описанного элемента. Таким образом, пространство имен по умолчанию применяется ко всем элементам внутри описанного элемента, которые явно не объявляют другое пространство имен для себя.
По умолчанию для пространства имен установлено стандартное значение для файлов WSDL: http://www.w3.org/ns/wsdl
TargetNamespace
Этот атрибут содержит пространство имен вашего веб-сервиса. Вы можете свободно выбирать это пространство имен, но есть соглашение о том, что URI должен указывать на WSDL службы.
Xmlns: ТНС
Это пространство имен должно быть установлено в тот же URI, что и атрибут targetNameSpace. Таким образом вы можете обратиться к целевому пространству имен с помощью этого префикса пространства имен (tns).
Ответ 4
пространство имен означает как область
Следующее изображение помогает понять XSD, используя аналогию с Java, насколько мне известно:
Ответ 5
Ни один из приведенных выше ответов не имел смысла для меня, пока я не прочитал что-то на веб-сайте Microsoft. Может быть, это поможет кому-то понять разницу между «targetNamespace» и «xmlns».
«Xmlns» делает одну вещь: он устанавливает пространство имен по умолчанию для всех xml (элементов и атрибутов) ВНУТРИ только вашего файла схемы.
«TargetNamespace» выполняет две функции: он изменяет пространство имен по умолчанию, заданное вами с помощью «xmlns», на новое пространство имен в файле схемы И устанавливает пространство имен для всех документов xml, полученных из него, а не внутри него. Единственным исключением является то, что его собственные элементы ссылаются на свои собственные типы внутри схемы (см. Ниже).
Давайте углубимся в детали, чтобы понять, что это значит:
«TargetNamespace» в схеме просто говорит синтаксическому анализатору переместить пространство имен из пространства по умолчанию в пространство имен «targetNamespace», где «xmlns» устанавливает пространство имен по умолчанию до того, как будет установлено «targetNamespace». «TargetNamespace» нельзя использовать, пока вы не установили пространство имен по умолчанию с помощью «xmlns».
Пример. Это работает, поскольку пространство имен по умолчанию было установлено сначала, а затем изменено:
Это терпит неудачу, поскольку сначала не установлено пространство имен по умолчанию:
Затем выясняется, что каждый документ XML или документ схемы имеет пустое пространство имен по умолчанию. Это то же самое, что сказать xmlns = «». Когда вы добавляете атрибут «xmlns = ‘xxxxx'» со значением, вы устанавливаете каждый тег и атрибут в файле xml в новое пространство имен по умолчанию. Вы не можете добавить «targetNamespace» до тех пор, пока оно не будет установлено, что является ИЗМЕНЕНИЕМ в пространстве имен для каждого тега в XML.
Давайте теперь поговорим о том, как используется новое пространство имен по умолчанию.
Когда вы устанавливаете для атрибута «xmlns» значение, вы просто говорите: сначала установите пространство имен по умолчанию, используя «xmlns». Позже, конечно, вы можете изменить его, даже на то же пространство имен по умолчанию, используя «targetNamespace» следующим образом:
Одно замечание об использовании цели с пустым пространством имен. Вы можете добавить «targetNamespace» в качестве дочерней ссылки или псевдонима в пустое пространство имен следующим образом. Это довольно часто:
Но что это значит? Пространство имен по умолчанию остается пустым (xmlns = «»), но псевдоним «tns» теперь доступен как дочерний элемент пустого пространства имен и используется для определения определенных элементов внутри вашего xml с использованием нового targetNamespace. В этом сценарии у вас есть пустое пространство имен, но определенные атрибуты внутри вашей схемы будут иметь свое собственное пространство имен с использованием псевдонима, например:
Затем это объясняет разницу между двумя атрибутами, но не объясняет, ПОЧЕМУ вам нужны оба «targetNamespace» и «xmlns».
Оказывается, что установка вашего пространства имен по умолчанию для вашей схемы, «xmlns = ‘xxxxx'», но НЕ установка целевого пространства имен, «targetNamespace = ‘xxxxx'», установит все ваши теги xml в новое пространство имен, но не будет разрешено снаружи xml-экземпляры, которые используют схему или даже вашу схему для доступа к своим собственным типам.
Таким образом, добавление «targetNamespace» не только меняет пространство имен xmlns по умолчанию, но и контролирует, как схема обращается к своим собственным типам. Например, приведенный ниже пример кода завершается ошибкой, так как в нем отсутствует targetNamespace. Это значение необходимо для того, чтобы схема присвоила пространству имен свой простой тип и получила доступ к этому простому типу из своего собственного элемента схемы ниже. Несмотря на то, что было назначено пространство имен по умолчанию, пользовательский «simpleType», доступный из элемента, не может получить к нему доступ, так как он не был связан с целевым пространством имен схемы. Это объясняет разницу:
Код ниже будет в порядке, так как targetSchema был добавлен и сообщает схеме, что ее типы также являются частью пространства имен и доступны, и схема может ссылаться на свои собственные типы, используя новое пространство имен без псевдонима.
Любой, кто спроектировал эту систему XSD схемы, должен вернуться к чертежной доске, если вы спросите меня. Но, по крайней мере, это помогает понять, с чем мы застряли.
Ответ 6
Другие ответы здесь хороши, поэтому я не буду повторять их объяснения здесь. Тем не менее, если кто-то из Java-фона, найдет его проще, вот аналогия, которую я придумал:
Заявление, вы объявляете в верхней части ваших классов Java.
Рассмотрим (для аналогии), если у вас был один пакет в вашем проекте Java, и все классы объявлены и определены в одном внешнем классе. Например,
В проекте Java вы должны импортировать библиотеку, используя pom.xml (или build.gradle ) следующим образом:
В XML вы «импортируете» схему, используя
Ответ 7
После тщательного тестирования с использованием xmllint, я думаю, что нашел здесь определенное объяснение. Рассмотрим приведенную ниже схему:
Вышеприведенная схема проверяет следующий документ:
Причина, по которой работает, состоит в том, что xmlns = «http://yyyzzz.com» автоматически связывается с элементом, который также определяется схемой! Это означает, что он также привязывается к элементу recipeType.
Теперь, с тем же документом xml, но с немного модифицированной схемой, как показано ниже, также проверяется и внимательно изучает разницу:
Документ xml даже не заботится о префиксе EGboy, этот префикс предназначен только для того, чтобы схема ссылалась на соответствующие xmlns, если их много.
targetNamespace и xmlns без префикса, в чем разница?
в документе схемы xml, если у меня есть как targetNamespace, так и xmlns без префикса.
какова точная разница между ними? Я понимаю, что если у вас есть xmlns без префикса, все элементы без префикса получают это пространство имен и. смутно то же самое касается targetNamespace.
5 ответов:
по моему опыту, многие авторы XML-схемы считают это «лучшей практикой». так что вы на правильном пути.
в терминах XSD, targetNamespace предписывает часть пространства имен полного имени компонента схемы, который включает элементы, атрибуты, группы и группы атрибутов, а также простые и сложные типы. Некоторые из них полные имена, определенные в XSD (элементы и атрибуты), «непосредственно» используются документом экземпляра XML. На другие, например для типов, можно ссылаться через атрибут xsi:тип атрибут в экземпляре XML-документов. Остальные (группы, группы атрибутов) существуют для облегчения композиции схемы (через ссылки).
чтобы соответствовать существующему XML. В в этом случае, если ваш XML использует пространства имен, для каждого из используемых пространств имен вы получите элемент схемы XSD с соответствующим атрибутом targetNamespace.
для тех, кто все еще смущен, рассмотрим эти три xsds. Все они определяют один глобальный тип и одно глобальное определение элемента, которое ссылается на него.
во-первых, xsd, как тот, который размещен выше. Он использует префикс xsd-схемы для схема пространство имен и пространство имен по умолчанию для атрибута targetnamespace:
Теперь тот же xsd, но определение и использование префикса пространства имен для целевого пространства имен:
. и, наконец, версия, которая использует пространство имен по умолчанию вместо » xsd » для пространства имен схемы XML:
большинство авторов схемы выбрать первый или последний, потому что если объект пространства имен по умолчанию отсутствует, то мы могли бы также использовать что-то.
атрибут xmlns задает пространство имен по умолчанию для описываемого элемента. Таким образом, пространство имен по умолчанию применяется ко всем элементам внутри описанного элемента, которые явно не объявляют другое пространство имен для себя.
пространство имен по умолчанию имеет стандартное значение для файлов WSDL:http://www.w3.org/ns/wsdl
targetNameSpace
этот атрибут содержит пространство имен веб-сервиса. Вы можете свободно выбирать это пространство имен, но есть соглашение, в котором говорится, что URI должен указывать на WSDL службы.
xmlns:tns
Это пространство имен должно иметь тот же URI, что и атрибут targetNameSpace. Таким образом, вы можете ссылаться на целевое пространство имен через этот префикс пространства имен (tns).
xmlns атрибут используется для ссылки на элементы и типы данных, которые поступают из значения атрибута xmlns для текущей области элемента.
следующее изображение помогает понять XSD, используя аналогию Java в соответствии с моими знаниями:
после некоторого тщательного тестирования с помощью xmllint Я думаю, что нашел определенное объяснение здесь. Рассмотрим следующую схему:
приведенная выше схема проверяет следующий документ:
причина, которая работает, потому что xmlns=»http://yyyzzz.com» автоматически привязывается к элементу, определяемому схемой тоже! Это означает, что он также привязывается к recipeType элемент.
Теперь, с тем же xml документ, но с немного измененной схемой, как показано ниже, также проверяет и внимательно изучает разницу:
игнорировать, если другой xmlns пропал, но вместо этого посмотрите внимательно на type= «EGboy: recipeType». Мы больше не можем полагаться на xmlns потому что он имеет другое значение, поэтому мы должны поставить префикс EGboy перед recipeType.
xml-документ даже не заботится элемент EGboy префикс этот префикс предназначен только для схемы, чтобы ссылаться на правильный xmlns в случае, если есть много.
Задание целевого пространства имен с помощью атрибута targetNamespace (SQLXML 4.0)
Атрибут xsd: targetNamespace можно использовать для размещения элементов и атрибутов из пространства имен по умолчанию в другом пространстве имен. Можно указать, будут ли локально объявленные элементы и атрибуты схемы уточняться пространством имен, использоваться явно путем применения префикса либо использоваться неявно. Вы можете использовать атрибуты elementFormDefault и attributeFormDefault в элементе, чтобы глобально указать квалификацию локальных элементов и атрибутов, или можно использовать атрибут Form для указания отдельных элементов и атрибутов по отдельности.
Примеры
Чтобы создать рабочие образцы на основе следующих примеров, необходимо выполнить определенные требования. Дополнительные сведения см. в разделе требования для запуска примеров SQLXML.
A. Указание целевого пространства имен
Объявления типов CustomerType и OrderType являются глобальными и, следовательно, включаются в целевое пространство имен схемы. В результате, если на эти типы имеется ссылка в объявлении элемента и его дочернего элемента, указывается префикс, связанный с целевым пространством имен.
Элемент также включается в целевое пространство имен схемы, поскольку это глобальный элемент в схеме.
Выполните следующий XPath-запрос к схеме:
Этот XPath-запрос создает следующий экземпляр документа (показаны только несколько заказов):
Этот экземпляр документа определяет пространство имен urn: MyNamespace и связывает с ним префикс (y0). Префикс применяется только к глобальному элементу. (Элемент является глобальным, так как он объявлен как дочерний элемент в схеме.)
Создание рабочего образца этой схемы
Скопируйте приведенный выше код схемы и вставьте его в текстовый файл. Сохраните файл с именем targetNameSpace.xml.
Скопируйте следующий шаблон и вставьте его в текстовый файл. Сохраните файл с именем targetNameSpace.xml в тот же каталог, куда уже был сохранен файл targetNamespace.xml.
Запрос XPath в шаблоне возвращает элемент для клиента с идентификатором CustomerID, равным 1. Обратите внимание, что в запросе XPath префикс пространства имен указан для элемента запроса, а не для атрибута. (Как указано в схеме, локальные атрибуты не определены).
Указанный для схемы сопоставления путь к каталогу (targetNamespace.xml) задается относительно каталога, в котором сохранен шаблон. Можно также задать абсолютный путь, например:
Создайте и запустите тестовый скрипт SQLXML 4.0 (Sqlxml4test.vbs), чтобы выполнить шаблон.
Если схема задает атрибуты elementFormDefault и attributeFormDefault со значением «квалифицированный», то в документе экземпляра будут определены все локальные элементы и атрибуты. Можно изменить предыдущую схему, чтобы включить эти атрибуты в элемент, и снова выполнить шаблон. Так как атрибуты в экземпляре теперь также имеют квалификатор, XPath-запрос изменится так, чтобы включать префикс пространства имен.
Шаблоны проектирования XSD
В жизни каждого аналитика и программиста наступает такой день, когда он узнает о существовании шаблонов (паттернов) проектирования XML-схем и его жизнь меняется. Для меня, например, с этого знания началось постижение красоты проектирования.
Сегодня хочу поговорить о том, какие есть шаблоны проектирования XSD, о преимуществах и недостатках каждого, и почему мы для своих задач выбрали «Райский сад».
Для примера возьмем следующий XML-документ в качестве источника данных.
И посмотрим, как можно описать одну и ту же структуру XML-документа разными способами.
В основе разделения на шаблоны лежит принцип определения глобальных элементов и/или типов данных внутри XSD.
Матрешка (Russian Doll)
Суть шаблона в том, что схема является зеркалом описываемого ею XML-документа: если сложные элементы содержат внутри себя другие сложные элементы, а те в свою очередь содержат простые, то и в XSD описания таких элементов будут вложены друг в друга. Название шаблон получил в честь известной во всем мире нашей куклы-матрешки, по аналогии с тем, как дочерние элементы в шаблоне инкапсулируются в родительские.
Схема, описывающая структуру нашего файла-источника с использованием шаблона «Матрешка», выглядит так:
Салями (Salami Slice)
Суть шаблона в том, что описываемый XML-документ разделяется на составные элементы, каждый из которых описывается в XSD как глобальный. Затем описанные элементы соединяются воедино.
Схема, описывающая структуру файла-источника с использованием шаблона «Салями», выглядит так:
Венецианские жалюзи (Venetian Blind)
Суть шаблона в том, что описываемый XML-документ разделяется на составные типы, каждый из которых описывается в XSD как глобальный. Затем объявляется корневой элемент, соответствующий глобальному типу, соединяющему схему воедино.
Схема, описывающая структуру файла-источника с использованием шаблона «Венецианские жалюзи», выглядит так:
Райский сад (Garden of Eden)
«Райский сад» хорош тем, что определяет каждый элемент и составной тип данных как глобальный. Это позволяет ссылаться на любой тип или элемент в пределах одного XSD или из любой другой XSD и даже из WSDL. Только так можно полностью контролировать семантику и типов и элементов.
Схема, описывающая структуру файла-источника с использованием шаблона «Райский сад», выглядит так:
Выбор шаблона
Часто при выборе шаблона проектирования приходится искать баланс между возможностью повторно использовать компоненты схемы и глубиной взаимосвязи между компонентами. На рисунке показан потенциал каждого из шаблонов в разрезе этих двух аспектов.
Те схемы, в которых хорошо поддерживается повторное использование компонентов, с другой стороны имеют сильные взаимосвязи между компонентами. При необходимости что-то поменять в такой схеме разработчик схемы может столкнуться с тем, что менять придется много связанных элементов и/или типов. Такими схемами впоследствии трудно управлять.
Нам в проекте важнее всего было повторное использование типов и элементов схемы и во вторую очередь тотальный семантический контроль имен. Выбор шаблона был очевиден – Райский сад.
Небольшое лирическое отступление. Самым интересным применением шаблонов проектирования XML-схем на моей памяти был и остается гипноз аудитории. Один наш титулованный аналитик любит брать инициативу в свои руки через рассказ на эту тему. Засекала время, через 5 минут взгляд слушателей тускнеет, и они уходят куда-то далеко в себя. На «Райском саде» сознание большинства отключается.
И в заключении хочу добавить, что миксы шаблонов тоже возможны, мы с ними встречались.