Xmlns xsi что это
Русские Блоги
Взаимосвязь и роль 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, и элементы, измененные префиксом, должны соответствовать спецификациям схемы. Например:
Пример XML схемы
В этой главе будет показано, как писать XML схемы. Также вы узнаете, что схемы можно писать разными способами.
XML документ
Давайте посмотрим на следующий XML документ под названием «shiporder.xml»:
Приведенный выше XML документ состоит из корневого элемента shiporder с обязательным атрибутом orderid. Элемент shiporder содержит три дочерних элемента: orderperson, shipto и item. Элемент item используется дважды и содержит элемент title, необязательный элемент note, а также элементы quantity и price.
Строка xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» говорит XML парсеру, что этот документ должен быть проверен на соответствие схеме. Строка xsi:noNamespaceSchemaLocation=»shiporder.xsd» указывает, где именно находится схема (в данном случае она находится в той же папке, что и файл «shiporder.xml»).
Создание XML схемы
Теперь для приведенного выше XML документа создадим XML схему.
Создадим новый файл, который назовем «shiporder.xsd». Для создания XML схемы будем просто следовать за структурой XML документа и определять каждый встреченный элемент. Начнем со стандартной XML декларации, за которой опишем элемент xs:schema, который и определяет саму схему:
Здесь мы используем стандартное пространство имен (xs) и URI, ассоциированный с этим пространством имен, который имеет стандартное значение http://www.w3.org/2001/XMLSchema.
Теперь мы должны определить элемент shiporder. У этого элемента есть атрибут, и он содержит другие элементы, поэтому мы рассматриваем его как элемент составного типа. Определения дочерних элементов элемента shiporder поместим в декларацию xs:sequence, что задает жесткую последовательность подэлементов:
Теперь определим элемент orderperson, который будет простого типа (так как он не содержит ни атрибуты, ни другие элементы). Его тип (xs:string) имеет префикс пространства имен, ассоциированного с XML схемой, что указывает на использование предопределенного типа данных:
Теперь нам нужно определить два элемента составного типа: shipto и item. Начнем с определения элемента shipto:
При помощи схем мы можем определить число возможных вхождений любого элемента. В этом нам помогут атрибуты maxOccurs и minOccurs. Атрибут maxOccurs задает максимальное число вхождений элемента, а атрибут minOccurs задает минимальное число вхождений. По умолчанию значение обоих атрибутов равно 1.
Теперь определим элемент item. Этот элемент может использоваться неограниченное число раз внутри элемента shiporder. Определить такую особенность элемента item позволяет присваивание атрибуту maxOccurs значения «unbounded». Это означает, что элемент item может использоваться столько раз, сколько нужно автору документа. Обратите внимание, что элемент note опционален. Определим это установив атрибут minOccurs в нулевое значение:
Теперь мы можем декларировать атрибут элемента shiporder. Поскольку это обязательный атрибут, используем определение use=»required».
Примечание: Атрибуты должны всегда декларироваться последними:
Вот полный код файла схемы «shiporder.xsd»:
Разделение схемы
Предыдущий способ компоновки схемы весьма прост, однако, когда документ достаточно сложен, при подобном способе соответствующая схема может оказаться довольно громоздкой, что сильно скажется на удобстве ее чтения и поддержки.
Следующий способ компоновки схемы заключается в том, что сначала определяются все элементы и атрибуты, а затем на эти определения создаются ссылки при помощи атрибута ref.
Ниже приводится новая компоновка файла схемы («shiporder.xsd»):
Использование поименованых типов
Третий способ компоновки схемы предполагает определение классов или типов, которые позволяют повторное использование определений элементов. Это становится возможным, если дать имена элементам simpleTypes и complexTypes, а затем указать на них при помощи атрибута type.
Третий способ компоновки файла схемы («shiporder.xsd»):
Элемент restriction указывает на то, что тип данных является производным от типов данных из пространства имен W3C XML Schema. Таким образом, следующий фрагмент кода означает, что значение элемента или атрибута должно быть строковым:
Однако гораздо чаще элемент restriction используется для накладывания ограничений на элементы. Посмотрите на следующие строки из приведенной выше схемы:
Этот фрагмент кода указывает, что значение элемента или атрибута должно быть строковым, ровно шесть символов в длину, и этими символами должны быть цифры от 0 до 9.
Про xmlns. Часть первая
 | /cc1.gif "Xmlns xsi что это. Смотреть фото Xmlns xsi что это. Смотреть картинку Xmlns xsi что это. Картинка про Xmlns xsi что это. Фото Xmlns xsi что это") |
/cc3.gif "Xmlns xsi что это. Смотреть фото Xmlns xsi что это. Смотреть картинку Xmlns xsi что это. Картинка про Xmlns xsi что это. Фото Xmlns xsi что это") | /cc2.gif "Xmlns xsi что это. Смотреть фото Xmlns xsi что это. Смотреть картинку Xmlns xsi что это. Картинка про Xmlns xsi что это. Фото Xmlns xsi что это") |
Атрибут 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-файлах объявлять неймспейс по умолчанию, или во всех не объявлять. Лично я везде не объявляю — меньше суеты в коде.
В следующей части мы подробнее разберемся в неймспейсах с префиксом.
Xmlns xsi что это
В этой главе будет показано, как писать XML схемы. Также вы узнаете, что схемы можно писать разными способами.
XML документ
Давайте посмотрим на следующий XML документ под названием «shiporder.xml»:
Приведенный выше XML документ состоит из корневого элемента shiporder с обязательным атрибутом orderid. Элемент shiporder содержит три дочерних элемента: orderperson, shipto и item. Элемент item используется дважды и содержит элемент title, необязательный элемент note, а также элементы quantity и price.
Строка xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance» говорит XML парсеру, что этот документ должен быть проверен на соответствие схеме. Строка xsi:noNamespaceSchemaLocation=»shiporder.xsd» указывает, где именно находится схема (в данном случае она находится в той же папке, что и файл «shiporder.xml»).
Создание XML схемы
Теперь для приведенного выше XML документа создадим XML схему.
Создадим новый файл, который назовем «shiporder.xsd». Для создания XML схемы будем просто следовать за структурой XML документа и определять каждый встреченный элемент. Начнем со стандартной XML декларации, за которой опишем элемент xs:schema, который и определяет саму схему:
Здесь мы используем стандартное пространство имен (xs) и URI, ассоциированный с этим пространством имен, который имеет стандартное значение http://www.w3.org/2001/XMLSchema.
Теперь мы должны определить элемент shiporder. У этого элемента есть атрибут, и он содержит другие элементы, поэтому мы рассматриваем его как элемент составного типа. Определения дочерних элементов элемента shiporder поместим в декларацию xs:sequence, что задает жесткую последовательность подэлементов:
Теперь определим элемент orderperson, который будет простого типа (так как он не содержит ни атрибуты, ни другие элементы). Его тип (xs:string) имеет префикс пространства имен, ассоциированного с XML схемой, что указывает на использование предопределенного типа данных:
Теперь нам нужно определить два элемента составного типа: shipto и item. Начнем с определения элемента shipto:
При помощи схем мы можем определить число возможных вхождений любого элемента. В этом нам помогут атрибуты maxOccurs и minOccurs. Атрибут maxOccurs задает максимальное число вхождений элемента, а атрибут minOccurs задает минимальное число вхождений. По умолчанию значение обоих атрибутов равно 1.
Теперь определим элемент item. Этот элемент может использоваться неограниченное число раз внутри элемента shiporder. Определить такую особенность элемента item позволяет присваивание атрибуту maxOccurs значения «unbounded». Это означает, что элемент item может использоваться столько раз, сколько нужно автору документа. Обратите внимание, что элемент note опционален. Определим это установив атрибут minOccurs в нулевое значение:
Теперь мы можем декларировать атрибут элемента shiporder. Поскольку это обязательный атрибут, используем определение use=»required».
Примечание: Атрибуты должны всегда декларироваться последними:
Вот полный код файла схемы «shiporder.xsd»:
Разделение схемы
Предыдущий способ компоновки схемы весьма прост, однако, когда документ достаточно сложен, при подобном способе соответствующая схема может оказаться довольно громоздкой, что сильно скажется на удобстве ее чтения и поддержки.
Следующий способ компоновки схемы заключается в том, что сначала определяются все элементы и атрибуты, а затем на эти определения создаются ссылки при помощи атрибута ref.
Ниже приводится новая компоновка файла схемы («shiporder.xsd»):
Использование поименованых типов
Третий способ компоновки схемы предполагает определение классов или типов, которые позволяют повторное использование определений элементов. Это становится возможным, если дать имена элементам simpleTypes и complexTypes, а затем указать на них при помощи атрибута type.
Третий способ компоновки файла схемы («shiporder.xsd»):
Элемент restriction указывает на то, что тип данных является производным от типов данных из пространства имен W3C XML Schema. Таким образом, следующий фрагмент кода означает, что значение элемента или атрибута должно быть строковым:
Однако гораздо чаще элемент restriction используется для накладывания ограничений на элементы. Посмотрите на следующие строки из приведенной выше схемы:
Этот фрагмент кода указывает, что значение элемента или атрибута должно быть строковым, ровно шесть символов в длину, и этими символами должны быть цифры от 0 до 9.
Для следующего фрагмента XML:
И есть 2 URL-адреса в xsi:schemaLocation=
Если 1 не существует, зачем его все еще класть?
Связанные с пространством имен атрибуты в XML и XML-схеме (XSD)
Префикс xmlns используется только для объявления привязок пространства имен и по определению связано с именем пространства имен http://www.w3.org/2000/xmlns/.
В вашем примере он объявляет, что http://maven.apache.org/POM/4.0.0 является пространством имен по умолчанию для элементов вашего проекта Maven.
xmlns:xsi объявляет стандартный префикс пространства имен ( xsi ) для используемого основного пространства имен в XSD: http://www.w3.org/2001/XMLSchema-instance
Схема XML: Структуры также определяют несколько атрибутов для прямого использования в любых XML-документах. Эти атрибуты находятся в другом пространстве имен, который имеет имя пространства имен http://www.w3.org/2001/XMLSchema-instance. Для краткости текст и примеры в этой спецификации используют префикс xsi: для этого последнее пространство имен; на практике может использоваться любой префикс.
xsi:type позволяет экземпляру XML напрямую связывать информацию типа элемента, а не через XSD, См. Как ограничить значение элемента XML с помощью xsi: type в XSD?
xsi:nil позволяет считать пустой элемент действительным, если XSD не может в противном случае разрешили его.
targetNamespace является атрибутом корня xs:schema элемент XSD, который определяет пространство имен корневого элемента экземпляров XML-документа, которые XSD предназначен для управления. Это должно соответствие по умолчанию или явное пространство имен этих корней XML-документов элементы.
Консорциум W3C выработал рекомендацию языка определения схем XML (XSD), объединив наиболее популярные языки описания схем в один стандарт. Основная цель, которая при этом преследовалась, — получение стандарта, который можно широко реализовать и при этом он платформно-независимый.
Язык XML Schema Definition Language, который также называют XML Schema Language, во многом похож на язык XDR, с которым вы познакомились раньше. Схемы XSD способны решать следующие задачи:
XML-документ, который проверяется с помощью схемы, также должен содержать объявление пространства имен. Пространство имен всегда указывается в корневом элементе экземпляра документа с помощью атрибута
Ссылка на конкретную схему приводится в атрибуте
Объявление элемента и атрибута XSD
Основное объявление элемента состоит из имени и типа данных
В схемах XSD дескрипторы, используемые в документах XML, разделяются на две категории — сложные типы и простые типы. Элементы сложных типов могут содержать другие элементы, а также обладают определенными атрибутами; элементы простых типов такими возможностями не обладают.
Атрибут – объявление простого типа, которое не может содержать другие элементы. Объявление атрибута похоже на объявление элемента:
Простые типы данных
Есть две главных категории простых типов:
Язык XSD имеет большое количество данных. Встроенные типы включают в себя примитивные типы и производные. данных не получены из других типов данных. Например, числа с плавающей запятой – математическое понятие, которое не получено из других типов данных. данных определены в терминах существующих типов данных. Например, целое число – частный случай, полученный из десятичного типа данных.
Следующая таблица представляет список примитивных типов данных XML-схемы, аспекты, которые могут быть применены к типу данных и описания типа данных.