Xsi type xs string 1с не выводить в xml
Мы можем контролировать, каким образом элементы должны использоваться в XML документах. Это позволяют сделать индикаторы.
Всего существует семь индикаторов:
Индикаторы очередности
Индикаторы очередности, как ясно из названия, используются для определения очередности появления элементов в XML документе.
Индикатор all
Индикатор устанавливает, что дочерние элементы могут появляться в документах в любом порядке, и что каждый из этих дочерних элементов должен появляться всего один раз:
Примечание: При использовании индикатора вы можете установить индикатор в значение 0 или 1, а индикатор только в значение 1 (индикаторы и описываются ниже).
Индикатор choice
Индикатор устанавливает, что появляться в документах может либо один дочерний элемент, либо другой:
Индикатор sequence
Индикатор устанавливает, что дочерние элементы должны появляться в документах в заданном порядке:
Индикаторы частотности
Индикаторы частотности используются для того, чтобы определить то, как часто элементы могут появляться в XML документах.
Примечание: Для всех "порядковых" и "групповых" индикаторов (any, all, choice, sequence, group name и group reference) значением по умолчанию для maxOccurs и minOccurs является 1.
Индикатор maxOccurs
Индикатор устанавливает максимальное количество появлений элемента:
В приведенном выше примере указывается, что элемент "child_name" в элементе "person" может использоваться минимум один раз (значение по умолчанию для индикатора minOccurs - 1) и максимум 10 раз.
Индикатор minOccurs
Индикатор устанавливает минимальное количество появлений элемента:
В приведенном выше примере указывается, что элемент "child_name" в элементе "person" может использоваться минимум 0 раз и максимум 10 раз.
Совет: Чтобы разрешить использовать какой-то элемент неограниченное число раз, используется выражение maxOccurs="unbounded".
XML файл "Myfamily.xml":
Приведенный XML файл содержит корневой элемент "persons". Внутри этого корневого элемента у нас есть три элемента "person". Каждый элемент "person" должен содержать элемент "full_name" и может содержать до 5 элементов "child_name".
А вот его файл схемы "family.xsd":
Индикаторы группирования
Индикаторы группирования используются для определения связанных наборов элементов.
Группирование элементов
Группы элементов определяются при помощи декларации group следующим образом:
Внутри такой декларации необходимо определять элемент all, choice или sequence. В следующем примере определяется группа с именем "persongroup", которая определяет группу элементов, которые должны появляться точно в указанном порядке:
После того как группа элементов была определена, вы можете использовать ее в других определениях:
Группирование атрибутов
Группы атрибутов определяются при помощи декларации attributeGroup:
В следующем примере определяется группа атрибутов с именем "personattrgroup":
После того как группа атрибутов была определена, вы можете использовать ее в других определениях:
Соединение и выполнение некоторых API команд происходит успешно, если в параметрах команд простые типы (Число, Дата, Булево), а если в параметрах необходимо передать Массив, или структуру то вызов не проходит.
Скорей всего необходимо Объект 1с (Массив, Структуру и т.п.) перевести в Тип который ожидает сервис.
ОбъектXDTO = Сериализатор.ЗаписатьXDTO(Новый Массив());
Ответ=Client.getCurrencyList("demo_api", "demo@example.com", "demo",ОбъектXDTO);
в первых 3 параметрах указывается информация аутентификации, а в 4 параметр надо для этой функции передать пустой массив.
При этом при вызове функции выдается ошибка
"Ошибка установки соответствия префикса и URI пространства имен"
Видимо надо каким то образом указать, что мой массив принадлежит тому пространству имен который ожидает сервис. Не пойму как это сделать
Подключение к веб сервису:
ОпределениеТ=Новый WSОпределения("http://www.drebedengi.ru/soap/dd.wsdl");
WSСервис=ОпределениеТ.Сервисы[0];
Client=Новый WSПрокси(ОпределениеТ, WSСервис.URIПространстваИмен, WSСервис.Имя, WSСервис.ТочкиПодключения[0].Имя);
За ранее хочу сказать, что с XDTO и сервисами только пытаюсь, что то делать, поэтому возможно неправильно использую термнилагию.
только один пакет "http://www.w3.org/2001/XMLSchema"
Пробовал написать вот так:
ПространствоИмен="http://www.w3.org/2001/XMLSchema";
Связывался с разработчиком, он говорит что этот параметр должен быть пустой, он служебный и заполнять его не надо.
Но при этом он ругается, что параметр не заполнен при вызове из 1с.
(6) 2 элемента ситуацию не спасло. все равно пишет
"Ошибка SOAP сервера: getCurrencyList: Parameter 'idList' must be an array"
попробовал записать этот объект в хмл вот такой код:
(9)
Первый вариант
"Ошибка при вызове метода объекта модели XDTO.
Второй вариант:
"Обязательный параметр не задан: :ddengiService:getCurrencyList(. idList. )"
Он посоветовал, поставить php там есть рабочий пример на пхп.
Пошел, ставить, поидее там же и будет видно какой должен быть XML запрос.
можешь сохранить в файл и дописать ипорт
смотри v8: Заполнение массива XDTO
82
targetNamespace="http://xml.apache.org/xml-soap"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
(16) Сохранил в файл, что ты указал. Далее в конфу в пакеты XDTO загрузил эту схему далее:
Ошибка:
как выглядит MAP в ХМЛ:
Что касается (14) (15) не совсем понял как импортировать это, поидее (16) уже готовый тип.
(18) Сохранил wsdl далее в какое место файла необходимо вставить:
Выдается ошибка при выполнении:
"Фатальная ошибка:
Extra content at the end of the document
Не совсем понял, для чего ты указываешь:
"Там в файле есть секция определяющая путь к первису и точки подключения"
Смотри v8: Заполнение массива XDTO
82 там после
импорт идет в секции типов Попробуй создать эту секцию со свои пространством имен
Добавил вот это:
В прокси появились доп. пакеты:
"http://schemas.xmlsoap.org/soap/encoding/"
Ошибка:
Несоответствие типов XDTO:
Тип 'Map' не найден
Тип объекта не является открытым
(29) ты указал на код "Set currency list"
поидее, это какая то запись в базу.
В параметрах надо указать "list" думаю это не тоже самое, что и "idList" в параметрах вызова операции getCurrencyList
Судя по всему Веб сервис там ожидает только числовые значения, т.к. выдается ошибка на какой то другой
Попробовал указать 0, тогда вызов проходит getCurrencyList (думал это уже не случится=)), но ответ приходит пустой.
Написал еще разработчику, может подскажет какими значениями надо заполнить параметр idList чтобы получить норм ответ.
Serginio1, а как то можно в схеме wsdl которую мы указываем, для параметра idList указать, что он не является обязательным?
Когда в конфу загружаешь по ссылке wsdl, то там у параметров показывается свойство: Возможно пустое, там оно везде Ложь
(34) Возможно ошибки были при возврате значения
v8: Заполнение массива XDTO
см 100 Там точно возвращался map а 1С не могла разобрать этот тип
(37) у меня возвращается Неопределено, и ошибки не выскакивает
Ошибка:
Ошибка разбора XML: - [79,28]
Фатальная ошибка:
Попробовал просто удалить эту строку idList, тогда параметр не требуется но при вызове функции, но сервер все равно выдает ошибку:
Т.е. это на стороне сервера.
(38) Знач проблема на сервере или что то нужно подставлять по умолчанию
minOccurs это для полей структуры. Хрень сморозил. Есть понятие возможно пустое значение, но туда передается anySimpleType
Нашел еще один варинат работы через SOAP клиент, с помощью , но результат тот же.
Ошибка:
"Произошла исключительная ситуация (Client): Client:Incorrect number of parameters supplied for SOAP request HRESULT=0x80070057: Параметр задан неверно.
- Client:Unspecified client error. HRESULT=0x80070057: Параметр задан неверно."
Уже можно указать "" в качестве параметра, но при попытке выполнить выдает:
Произошла исключительная ситуация (SoapMapper): SoapMapper:Restoring data into SoapMapper anyType failed HRESULT=0x8007000E: Недостаточно памяти для завершения операции.
- Client:Unspecified client error. HRESULT=0x8007000E: Недостаточно памяти для завершения операции.
Думал, мб с 1с что то. Сделал подключение через SoapClient с помощью AutoIT результат, тот же не удается выполнить команды.
(43) у меня что то проблемы с установкой PHP на комп, точнее с портом 80.
Пробовал Денвер, поидее ничего не надо прописывать, устанавливаешь и все.
Вообщем пока php код не могу выполнить.
Далее в коде пытаюсь выполнить:
Объект = Фабрика.Создать(Фабрика.Тип("http://www.w3.org/2001/XMLSchema-instance","nil"));
Это неопределено в отладчике.
А вот если присвоить это значение какомунибудь anyType она правильно прописывает.
"А вот если присвоить это значение какомунибудь anyType она правильно прописывает."
Возможно, но как это сделать, чтобы передать в параметр WS операции.
В XML файле получается так:
При вызове операции выдается ошибка.
Ошибка SOAP сервера: getCurrencyList: Parameter 'idList' must be an array
(69) Вообще то nillable="true" для anyType это не совсем то. Кстати, а что возвращает то сервис?
Ответ от разработчика:
"Вам нужно добиться, чтобы передаваемый XML был таким-же, как у PHP скрипта.
На самом деле не только у PHP скрипта, многие стандартные библиотеки, в частности под все мобильные устройства - тоже умеют это делать, т.к. независимые разработчики это реализовали в приложениях.
Каким должно быть значение параметра, чтобы 1с сгенерил такой XML - вам нужно разобраться."
(70) сервис вернет, поидее массив записей о движениях, вроде как.
"и что возвращает http://www.soapui.org"
Честно говоря не понял, для чего этот сервис.
"Нагрузочное тестирование веб сервисов" ?
странно, что он выдает ответ
Ошибка SOAP сервера: getCurrencyList: Parameter 'idList' must be an array
А какой эррай если передается nil?
Понимаю, что это не особо средствами 1с. Но все же, лучше чем ничего.
Огромное спасибо за помощь Serginio1
(81) А объекты ты можешь из XML ответа подгружать используя прокси фабрику.
(80) А 64 не подошел?
(86) Почему то при чтении выдает ошибку
в wsdl в шапке прописано
Стал разбираться с возможно пустой параметр. nillable в параметрах не прокатывает
в 1с для параметров городится структура г де у параметра указывается nillable например
В этой главе будет показано, как писать 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, который и определяет саму схему:
Теперь мы должны определить элемент 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:
Что означают атрибуты xmlns , xmlns:xsi и xsi:schemaLocation ? Как они связаны? Что для : для?
И есть 2 URL-адреса в xsi:schemaLocation=
Если 1 не существует, зачем его все еще класть?
Связанные с пространством имен атрибуты в XML и XML-схеме (XSD)
xsi:type позволяет экземпляру XML напрямую связывать информацию типа элемента, а не через XSD, См. Как ограничить значение элемента XML с помощью xsi: type в XSD?
В вашем примере , xsi:type не используется; включенный здесь для полноты относительно xsi .
xsi:nil позволяет считать пустой элемент действительным, если XSD не может в противном случае разрешили его.
В вашем примере , xsi:nil не используется; включенный здесь для полноты относительно xsi .
xsi:schemaLocation и xsi:noNamespaceSchemaLocation предоставляют подсказки для XML-процессор относительно того, как связать XSD с XML-документом. Используйте xsi:schemaLocation , когда есть пространство имен; используйте xsi:noNamespaceSchemaLocation , когда нет пространства имен.
Если ваш пример не использовал пространство имен, вы должны использовать xsi:noNamespaceSchemaLocation , значение которого представляет собой единственный XSD-location-URI , который намекает на местоположение предполагаемого XSD и который должен быть извлечен.
targetNamespace является атрибутом корня xs:schema элемент XSD, который определяет пространство имен корневого элемента экземпляров XML-документа, которые XSD предназначен для управления. Это должно соответствие по умолчанию или явное пространство имен этих корней XML-документов элементы.
Консорциум W3C выработал рекомендацию языка определения схем XML (XSD), объединив наиболее популярные языки описания схем в один стандарт. Основная цель, которая при этом преследовалась, — получение стандарта, который можно широко реализовать и при этом он платформно-независимый.
Язык XML Schema Definition Language, который также называют XML Schema Language, во многом похож на язык XDR, с которым вы познакомились раньше. Схемы XSD способны решать следующие задачи:
- Перечисление элементов в документе XML и проверка наличия в документе только объявленных элементов.
- Объявление и определение атрибутов, модифицирующих элементы документа.
- Определение родительско-дочерних отношений между элементами.
- Определение состояний и моделей содержания для элементов и атрибутов.
- Задание типов данных.
- Установка значений по умолчанию.
- Возможность расширения.
- Поддержка использования пространств имен.
Корневым элементом в схеме XML является элемент , который содержит все остальные элементы в документе схемы. В рамках корневого элемента схемы XSD атрибутом определяется пространство имен , которое содержит элементы и атрибуты XSD схемы.
Все элементы XSD начинаются с префикса , который указывается для пространства имен XSD, объявленного в корневом элементе экземпляра схемы.
XML-документ, который проверяется с помощью схемы, также должен содержать объявление пространства имен. Пространство имен всегда указывается в корневом элементе экземпляра документа с помощью атрибута
Это пространство имен содержит элементы и атрибуты , которые можно включать в документ XML. По общему соглашению префикс используется для этого пространства имен и добавляется в начале имен всех элементов и атрибутов, принадлежащих пространству имен, отделяясь от них двоеточием.
Ссылка на конкретную схему приводится в атрибуте
Объявление элемента и атрибута XSD
Процесс создания схемы включает в себя два шага — определение и объявление типов элементов или типов атрибутов. Элементы и атрибуты XML-документа объявляются элементами схемы и . Структура же XML-документа определяется элементами схемы и .
Основное объявление элемента состоит из имени и типа данных
В схемах XSD дескрипторы, используемые в документах XML, разделяются на две категории — сложные типы и простые типы. Элементы сложных типов могут содержать другие элементы, а также обладают определенными атрибутами; элементы простых типов такими возможностями не обладают.
Атрибут – объявление простого типа, которое не может содержать другие элементы. Объявление атрибута похоже на объявление элемента:
Простые типы данных
Есть две главных категории простых типов:
- встроенные типы;
- определенные пользователем простые типы.
Язык XSD имеет большое количество данных. Встроенные типы включают в себя примитивные типы и производные. данных не получены из других типов данных. Например, числа с плавающей запятой – математическое понятие, которое не получено из других типов данных. данных определены в терминах существующих типов данных. Например, целое число – частный случай, полученный из десятичного типа данных.
Следующая таблица представляет список примитивных типов данных XML-схемы, аспекты, которые могут быть применены к типу данных и описания типа данных.
Следующая таблица представляет список производных типов данных XML-схемы, аспекты, которые могут быть применены к типу данных и описания типа данных.
Определённые пользователем простые типы
Получены из встроенных типов, применением к ним именованых ограничений, называемыми аспектами(Facets). Аспекты ограничивают допустимые значения простых типов. Синтаксис применения аспектов ограничения следующий:
Аспекты могут быть указаны только однажды в определении типа, кроме и – они могут иметь многократные вхождения и группируются.
Именованный тип данных
В языке XSD, в отличие от тех двух, с которыми вы познакомились раньше, существует концепция именованных типов. Например, при создании определения, можно присвоить этому определению имя, чтобы повторно использовать его в схеме XSD. Вы можете создать определение простого типа и назвать его, например, . В результате вы получите именованное ограничение. После этого вы сможете применять это ограничение и к другим элементам в схеме. Это особенно полезно, когда в определении применяются аспекты ограничения типа данных, чтобы не повторять их каждый раз в других определениях. Например, элемент может быть связан с элементом и атрибутом для объявления содержания этих элемента и значения атрибута как строковых данных:
Обратили внимание на ключевое слово в объявлении атрибута? Как и в предыдущих схемах, оно все так же означает обязательность использования объявленного атрибута. Другими предопределенными значениями атрибута элемента схемы могут быть ключевые слова и . Если первое из них означает необязательность использования, то второе запрещает использование объявленного атрибута. Такая необходимость возникает в случае локального объявления ранее определенной группы атрибутов элементом схемы , например:
далее в контексте определения элемента сложного типа мы делаем ограничение на применение атрибутов этой группы:
Сложные типы данных
элемента сложного типа – формальное описание структуры и допустимого содержания элемента, которое используется для проверки правильности XML документа. Модели содержания Схемы предоставляют больший контроль структуры элементов, чем модели содержания DTD. Кроме того, модели содержания схемы позволяют проверять правильность смешанного содержания.
Модель содержания может ограничивать документ до некоторого набора элементных типов и атрибутов, описывать и поддерживать связи между этими различными компонентами и уникально обозначать отдельные элементы. Свободное использование модели содержания позволяет разработчикам изменять структурную информацию.
Перечень объявлений дочерних элементов приводится в структуре группирующих XSD-элементов choice, sequence, и all.
Элемент позволяет только одному из элементов, содержащихся в группе присутствовать в составе элемента. Элемент требует появления элементов группы в точно установленной последовательности в составе элемента. элемент позволяет элементам в группе быть (или не быть) в любом порядке в составе элемента.
Элемент используется для четкого определения группы и для ссылки к именованной группе. Вы можете использовать модель группы, чтобы определить набор элементов, которые могут быть повторены в документе. Это полезно для формирования определения комплексного типа. Именованную модель группы можно далее определить, используя , или дочерние элементы. Именованные группы должны определяться в корне схемы. При необходимости многократного использования перечня элементов, определенного в группе, не надо каждый раз писать этот перечень – достаточно дать ссылку на именованную группу
Определение элемента сложного типа
Определения сложных типов создаются с использованием элемента , его атрибутов и любых допустимых аспектов. Обычно, сложные типы будут содержать набор элементных объявлений, объявлений атрибутов и элементных ссылок.
One of the node called "datafield" has an element called "value". This may contain normal text content, or an html content (which I need to wrap in CData).
So, I created a base class (ProvisionDataField) with 2 classes inherits from it (ProvisionTextField, and ProvisionCDataField) as follows:
When I serialize,I get something like this:
All good except that I've been told that I have to remove the "xsi:type" from the xml. So instead, I need my generated xml to look like this:
Is that possible?
Just to give more info, I am communicating to external services (written in Java) using POX (Plain Old XML). Rather than writing xml manually, I created classes and using xml serialization to generate the xml. The "type" is just the result of me using inheritance. The other system doesn't know at all about this type, and doesn't want it either.
3 Answers 3
This is the answer I am looking for - it will ensure that the xsi:type resulted from XmlInclude attribute used in inheritance is omitted:
While this section will omit the xmlns:xsd and xmlns:xsi from the root
You will have to overwrite xmlwriter.
This blogpost (not mine) shows you how.
With this as the result.
@JohnSaunders It's even still in the 4.5 framework, deprecated to me means they will remove it in one of the next versions, which they clearly are not doing.
No need to override XmlWriter, just use an instance of XmlSerializerNamespace:
This will result in the xml having no namespaces at all.
EDIT: Changed to VB code
EDIT 2: Upon further testing, the test code I used only removed the namespace declarations from the resulting xml. My original test did not produce the xsi:type attributes on the elements even though I used the classes provided by the OP, so I cannot determine if the code that I posted will remove them, as John Saunder alluded to in the comments. I presumed that if the namespaces were removed, then the xsi:type attributes would also be removed, but the code I posted does not prove this.
В этой главе будет показано, как писать 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, который и определяет саму схему:
Теперь мы должны определить элемент 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.
Читайте также: