1с импорт схемы xsd завершен часть схем не была импортирована

Обновлено: 08.01.2025

XSD — это язык описания структуры XML документа. Его также называют XML Schema. При использовании XML Schema XML-парсер может проверить не только правильность синтаксиса XML документа, но также его структуру, модель содержания и типы данных. Многие так или иначе сталкивались с процедурой полной валидации, обеспечивающей соответствие документа заданной схеме или сообщающей о возможных ошибках. В данной статье речь пойдет о частичной валидации, кроме вышеописанного, позволяющей конструировать валидные документы «на лету». Мы разберемся, какие возможности может предоставить такой подход и способы его реализации.

Основная цель

Зачем вообще может понадобиться конструировать документ, обладающий заданными свойствами, и какими свойствами мы можем управлять? На первый вопрос ответ практически очевиден; большинство документов не являются просто текстом, а наделены некоторой семантикой. XML решает вопрос синтаксического представления, а схема – частично решает вопрос семантического значения. Благодаря соответствию документа схеме, можно выполнять над ним набор предопределенных действий, допустимых для целого класса валидных документов, будь то представление в другом формате, экспорт значимой части информации для конкретной задачи, импорт новой информации с учетом глобальных ограничений. Наиболее часто применяемый механизм в таком случае – это XSLT преобразование, смысл которого можно проиллюстрировать следующей диаграммой:

• Строго контролировать типизацию данных узлов и атрибутов;
• Определять порядок следования узлов, следить за наличием обязательных узлов и атрибутов;
• Требовать уникальность элементов в заданном контексте;
• Создавать вариантные узлы, требующие наличия одних атрибутов или других, в зависимости от контекста;
• Требовать выполнения определенного предиката на группе узлов или атрибутов.

Часто возникает желание модифицировать документ, уже отвечающий выбранной схеме, таким образом, чтобы он не потерял валидность. Здесь речь идет и о автоматических модификациях, например добавление веб-агентами (агрегаторами) информации в документ или модифицирующие запросы в XML-базу данных, так и о ручной модификации, скажем, в визуальном XML-редакторе. Операция полной валидации для больших документов может занимать существенное время, десятки секунд и более, что в целом препятствует использованию подхода «атомарное изменение – проверка – отказ/разрешение». А для визуальных редакторов хотелось бы еще больше – иметь возможность не только проверить атомарное действие, а предложить все допустимые по схеме варианты модификации конкретного узла. Однако, хорошие XML-редакторы умеют это делать, и мы попробуем разобраться каким образом у них это получается.

Необходимая информация о XML схеме

• Шаблоны (any, anyType, anyAttribute), позволяющие использовать любой элемент, соответствующий заданному пространству имен;
• Группы подстановки, определяющие набор типов, который может быть использован вместо конкретного описания типа;
• Количество повторений, определяющее для каждого элемента минимальное и максимально допустимое количество его вхождений в тип (обобщение операторов Клини: "*", "+").

Правило Unique Particle Attribution (однозначность определения частиц) требует, чтобы каждый элемент документа однозначно соответствовал ровно одной частице xsd:element или xsd:any в модели содержимого родительского элемента [2].

Вообще говоря, правило Unique Particle Attribution (UPA) не является жестким требованием к структуре XML схем, а только крайне желательной рекомендацией и часть используемых схем ему не соответствует. Рассмотрим простейший пример, иллюстрирующий нарушение правила однозначности определения частиц.

Построение валидатора

• ADD: создание подэлемента с типом x на позиции n;
• REMOVE: удаление подэлемента, стоящего на позиции n;
• MOVE: перенос элемента с позиции n на позицию m (хоть перенос и сводится к выполнению удаления и добавления элементов, но промежуточное состояние может нарушать валидность документа).

• Частица:
  • MinOccurs – минимальное число повторений терма (если 0, то терм становится опциональным);
  • MaxOccurs – максимальное число повторений терма (допустима бесконечность – inf).
  • Терм: описание элемента, шаблон, последовательность или выбор;
  
• Описание элемента (typedef):
  • Локальное имя;
  • Имя пространства имен (может быть опущено, тогда элемент считается допустимым в любом пространстве имен);
  • Группа подстановки – множество всех элементов, принимаемых в выражениях содержащих typedef;
  
• Шаблон (any):
  • Имя пространства имен, допустимого для элемента подстановки (может отсутствовать);
  
• Последовательность (sequence):
  • Последовательное перечисление допустимых частиц;
  
• Выбор (choice):
  • Множество допустимых частиц.
  

1. Построение недетерминированного конечного автомата (NFA) с заданным конечным состоянием S по заданной частице:
a. Установим начальное состояние n на S;

b. Если MaxOccurs частицы равен бесконечности (inf):
• Добавим новое промежуточное состояние t; получаемое из преобразования терма в NFA (случай 2); добавим эпсилон-ребра из t в n и из n в S:

c. Если MaxOccurs частицы – число m:
• Строим цепочку из (MaxOccurs-MinOccurs) преобразований терма, начиная из конечного состояния S, добавляя эпсилон-ребро из промежуточного состояния на каждом шаге в конечное состояние S;
Например, для MaxOccurs=4 и MinOccurs=2 получаем следующий автомат:

d. Достраиваем minOccurs копий преобразования терма от нового начального состояния n, до начального состояния, полученного на предыдущих шагах.

2. Построение недетерминированного конечного автомата с заданным принимающим состоянием S по заданному терму:
a. Если терм – шаблон (any):
• Создаем новое состояние b, и соединяем его с S ребром, помеченным типом терма, возвращаем b;

b. Если терм – описание элемента:
• Создаем новое состояние b, затем для каждого элемента группы подстановки создаем ребро из b в S, помеченное типом элемента и возвращаем b;

c. Если терм – выбор (choice):
• Создаем новое состояние b, для каждого элемента выбора создаем автомат (случай 1) и соединяем его эпсилон-ребрами с состоянием b и состоянием S. Возвращаем b;

d. Если терм – последовательность (sequence):
• Для каждого элемента выбора создаем автомат (случай 1) и соединяем полученные автоматы в обратном порядке, начиная с состояния S, и возвращаем первое состояние в цепочке;

Затем применим алгоритм Томпсона к полученным NFA [3], для построения детерминированных автоматов. Алгоритм Томпсона можно применить в тех же случаях, что и алгоритм построения детерминированного автомата Ахо и Ульмана, основанный на сворачивании одинаково помеченных не-эпсилон ребер [4]. Однако в ряде случаев по исходному автомату (созданному на шагах 1–2) алгоритм Ахо и Ульмана не сможет построить детерминированный автомат.

• Их метки являются описаниями типов с одинаковыми локальными именами и названиями пространства имен;
• Их метки – это названия шаблонов, с перекрывающимся областями;
• Метка одного ребра – шаблон, другого – описание типа, оба лежат в одном пространстве имен, и описание типа входит в область шаблона.

Применим предложенный алгоритм к каждому типу схемы и получим соответствие тип -> автомат, который умеет проверять потомков элемента этого типа.

Осталось решить последнюю задачу – выбор нужного конечного автомата при валидации операции над заданным элементом дерева. С этим нам поможет структура привязки типов валидации (PSVI, Post-Schema-Validation Infoset), порождаемая почти любым (например, MSXML или libxml) полным валидатором. Для любого элемента дерева она указывает на соответствующий ему тип в описании схемы – в точности тот, по которому мы порождали нужный автомат.

В нашем случае реализация структуры PSVI представляется ссылкой на тип схемы для каждого элемента дерева.

Операции MOVE и REMOVE не меняют тип операнда (поэтому не требуют изменения структуры PSVI), а операция ADD вместе с добавлением элемента x, потребует добавления в структуру PSVI типа x. Таким образом, вместе с изменением структуры мы меняем и информационное множество привязки типов валидации, решая задачу частичной валидации и поддерживая дерево PSVI без вызова внешнего валидатора.

После долгого молчания, вызванного тем, что я сейчас больше читаю, чем пишу (чукча читатель, а не писатель), я решил поделиться с вами небольшим обзором, в котором хочу рассказать о том, что я узнал о XDTO-пакетах и обо всем, что с ними связано. Сразу скажу, что в интернете есть документация на эту тему и вообще гугл никто не отменял, но, на мой взгляд, ее как-то маловато. Пусть будет еще. Итак.

С чего начинается.

С чего начинаются XDTO-пакеты для неискушенного разработчика? Для меня они начались с вопроса: "А что это еще за хренотень в дереве метаданных?" И еще я знал, что это что-то про xml. Но мы начнем не с этого. А с объекта ФабрикаXDTO. Как можно догадаться из названия, это фабрика объектов ( в частности, в разделе о шаблоне , или . Книга, хочу заметить, действительно стоящая, но мозголомная, скорее формата "справочник", а не "учебник". Вдобавок все, что там написано, сложно применимо к 1С. Когда-нибудь я разозлюсь и напишу здоровенную статью о шаблонах (привет, kote!), а то досадно, что некоторые 1С-программистов

Тут я просто вынужден послать вас ознакомиться с

Для этого примера я бы нарисовал такую диаграмму:

Обратите внимание, что объект "структурныйТип" (т.н. "чертеж") тоже был создан фабрикой, на основании "загадочных" строчек. Рассмотрим, что же это за строчки. Про метод "Тип" объекта "ФабрикаXDTO" синтакс-помощник пишет:

Не слишком информативно. Тем не менее понятно, что на основании какого-то пространства имен и имени типа метод "Тип" создает нам необходимый "чертёж". Про пространства имен можно почитать, например, в статье , или терзайте жужл запросом "xmlns". Вкратце же скажу, что это некая область, в которой вы можете определить свои xml-теги, и они будут означать именно то, что вы в них закладывали при определении. Например, тег < table> в пространстве имен, определяющем HTML-документ, означает описание таблицы, а в вашем собственном он может означать, например, блок описания стола. Чтобы их не путать и нужны пространства имен.

Все же XDTO-пакеты

Поскольку мы выяснили, что данные о пространстве имен берутся не из интернета, возникает вполне резонный вопрос: откуда же тогда, черт побери?! И вот тут мы подходим к тому самому разделу "XDTO-пакеты" в дереве метаданных в конфигураторе. Внимательный читатель, наверное, заметил (если еще не забыл после моих лирических отступлений), что в примере мы использовали объект "ФабрикаXDTO", нигде его не создавая. Все верно, в глобальном контексте 1С есть такой объект (я бы сказал ), который знает о куче разных пространств имен, уже описанных в конфигураторе и вообще в платформе. То есть для того, чтобы наш пример заработал, нам необходимо создать примерно такой XDTO-пакет:

То есть мы создали тип объекта "Номенклатура", в который добавили два свойства: "Наименование" и "ЗакупочнаяЦена". Обратите внимание, что при создании пакета мы задали ему то пространство имен, которое в дальнейшем будем использовать при создании объекта "структурныйТип". Если вы посмотрите конструктор свойств, то можете увидеть там много интересного. Например, для моего свойства "Наименование" я использовал тип "string (http://www.w3.org/2001/XMLSchema)". Запомните это пространство имен. В нем описаны все базовые типы, которые вы можете использовать в своих объектах, такие как "string", "int" и так далее. После того как мы добавили пакет, объект "ФабрикаXDTO" знает о нашем пространстве имен и описанных в нем типах.

Нужно помнить, что пространства имен, описанные в разделе дерева метаданных "XDTO-пакеты", доступны только на сервере. При попытке обратиться к ним из клиентского кода (так же как и при других ошибках) метод "Тип" вернет "Неопределено". Этот момент несколько раздражает при отладке, мне кажется, что лучше бы оно ругалось чем-нибудь вроде "Тип не найден", но "маємо те, що маємо".

В своих объектах вы можете использовать и собственные типы из вашего пространства имен. Например, давайте добавим единицы измерения:

В качестве типа для свойства "ЕдИзм" я установил тип "ЕдиницаИзмерения (http://www.1c.ru/demos/products1)", просто выбрав его из дерева определенных в конфигурации типов.

А вот код, который создает этот объект:

Надеюсь, принцип понятен. Можете самостоятельно поиграться со свойствами, типами, объектами и прочим. Там есть куда "потыкать пальцем" и чего попробовать. А я тем временем продолжу.

Сериализировали-сериализировали

Что полезного мы уже можем извлечь из того, что знаем? Во-первых, объекты XDTO прекрасно сериализуются (XML же, как вы помните).

Дополним код вот таким фрагментом:

На выходе мы получим вот такой файл:

Теперь вы можете послать его друзьям по электронной почте, если, конечно, их интересуют женские ботинки. =)

Но поскольку объекты сериализуются, то они так же замечательно и десериализуются.

Вы когда-нибудь разбирали xml-файлы построчно, вылавливая значки "больше"-"меньше" бесконечными "Найти" и "Сред/Лев/Прав"? А пользовались ли вы замечательным объектом "ЧтениеXML" для разбора файла по тегам, которые потом приходилось разгребать вручную в какую-нибудь структуру? Теперь, если у вас правильно описаны XDTO-пакеты и типы в них, вы можете загружать xml сразу в объект и дальше работать с ним как с объектом. На мой взгляд, это замечательно и удобно.

К тому же при загрузке xml-файла происходит его валидация на соответствие типу, и в случае ошибки метод вызывает исключение. Поэтому, конечно же, правильный код по загрузке xml будет такой:

Что еще полезного можно получить из XDTO-пакетов? А вот что! Также мы можем очень просто выгружать объекты метаданных. В конфигурации есть пространство имен, в котором есть все типы XDTO присутствующих в конфигурации метаданных.

Добавим справочник "Клиенты", создадим в нем один элемент и напишем такой код:

В первой части кода, там, где мы получаем объект, ничего интересного не происходит, мы просто получаем объект (весьма коряво, надо отметить, но для примера пойдёт).

Зато обратите внимание на пространство имен и имя объекта в строчке, где создается объект "клиентыТип". В пространстве имен "http://v8.1c.ru/8.1/data/enterprise/current-config" должны быть описаны все объекты метаданных конфигурации, в чем вы можете убедиться, если посмотрите его в конструкторе XDTO-пакетов. Дальше уже знакомая процедура - сохранение объекта в XML.

Вот что получилось у меня:

Как видите, тут есть все реквизиты, включая стандартные ("Наименование", "Код"), а также ссылка ("Ref") и пометка на удаление ("DeletionMark").

Естественно, этот файл также можно загрузить обратно в объект. Код, надеюсь, вы уже можете написать сами.

В помощь юному падавану-сериализатору в 1С есть объект "СериализаторXDTO". Он также представлен как "синглтон", доступный в глобальном контексте, и как отдельный тип. В принципе, строки:

можно смело заменить на:

Код получился короче и работает более корректно. Например, если в справочнике "Клиенты" определены табличные части, то "ЗаполнитьЗначенияСвойств" с их заполнением не справится. А сериализатор - запросто. Теперь, когда (я надеюсь) вы понимаете основные принципы работы XDTO-пакетов, вы запросто разберетесь с тем, что еще можно делать с сериализатором. Да пребудет с вами сила синтакс-помощника. А я продолжу.

XDTO-пакет?

Конечно, без описания типа вам не обойтись. Но конфигуратор для этого не нужен. И тут нужно рассмотреть такую замечательную вещь, как xml schemа. XML-cхема - это как раз и есть описание типа, представленное (внимание

А теперь нажмите на кнопку "Экспорт XML-схемы. " (выглядит как ящик с листиком бумаги и стрелочкой) и сохраните схему в файл address.xsd

У меня получилось вот что:

Теперь удалите этот пакет из конфигурации, будто его и не было. Попробуем прочитать схему и создать по ней объект.

Вот код, который это делает:

Здесь мы для разнообразия не стали использовать глобальный объект "ФабрикаXDTO", а создали собственный функцией "СоздатьФабрикуXDTO". Если вы посмотрите в отладчике на нашу фабрику ("МояФабрикаXDTO"), то увидите, что в коллекции пакетов у нее всего два пакета: "http://www.w3.org/2001/XMLSchema" и "http://www.1c.ru/demos/products2", в отличие от "синглтона" "ФабрикаXDTO", где их существенно больше. В качестве бонуса мы получили то, что этот код может быть полностью исполнен на клиенте, так как не зависит от метаданных конфигурации.

На выходе я получил xml-файл, в который был сериализован мой объект:

Как вы видите, я поработал с объектом и сериализовал его без участия метаданных конфигурации. Таким образом, передавая вместе с xml-файлом также и XML-схему, вы можете быть уверенным, что тот, кто должен его получить, сможет разобраться, что с ним делать, а главное, как.

Пример десериализации приводить не буду, оставляю вам как самостоятельное упражнение.

Напоследок скажу, что можно выгрузить XML-схему всей вашей конфигурации, кликнув правой кнопкой по узлу "XDTO-пакеты". Результат получается поучительный, посмотрите.

Еще: если у вас есть xml-файл, с ним хочется поработать как с объектом, а XML-схему прислать никто не удосужился, вы можете воспользоваться замечательным инструментом xsd.exe из .NET Framework. (У себя я нашел его в папке "C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\".) Пользоваться им очень просто: даете ему на вход xml, на выходе получаете xsd. Вообще-то этот xsd не всегда (или вообще никогда?) является файлом сразу же "готовым к употреблению" в 1С, но все равно это существенная помощь в создании XML-схемы.

Как видите, все оказалось достаточно просто.

На этом всё

Несмотря на то что статья оказалась неожиданно длинной, нельзя сказать, что все, что здесь описано, претендует на полноту. Пытливый исследователь XML-мира с легкостью напишет целую книгу по каждому абзацу этого небольшого обзора и еще ворох по тому, о чем здесь не сказано. Например, о том, что "вся эта кухня" тесно связана с web-сервисами. Тема обширна, так что дерзайте. Также я могу в чем-то заблуждаться, поэтому пишите комментарии - буду исправлять. Давайте учиться вместе.

А я желаю вам хорошего дня и хорошего кода. До новых встреч.

Прилагаю к статье dt-шник с примерами.

UPD.2: На инфостарте появились еще две прекрасные статьи об XDTO, так что если что-то не понятно из моей, обязательно посмотрите их: XDTO - это просто и XDTO - это просто, часть 2

Есть очень много статей о том, как работать с XSL/XSD из 1С, но все они в стиле: возьмем нашу XSD схему (простую и удбоную) или наш web-сервис и смотрите, как все легко экспортировать или импортировать. А что делать, если нам дали пачку XSD-схем со сложным взаимосвязями и изменять мы них не можем, а работать и поддерживать актуальность схем надо?

Сразу скажу, вопросы шифрования/подписи по ГОСТУ при работе с ГИС ЖКХ за рамками этой статьи и на хабре уже освещались. Хотя без подписей запросы выполнить не удастся.

Начнем с простого — скачаем пакет форматов по интеграционному взаимодействию с ГИС ЖКХ, импортируем все xsd схемы из пакета интеграций, наведем порядок переименуем все как нам удобно. В итоге получим как показано на картинке:

Ну а теперь приступим к магии. Попробуем запросить данные из справочника организаций по ОРГН. Это подсистема organizations-registry-common метод exportOrgRegist.

В hcs-organizations-registry-common-service.wsdl указано:

Спецификация из hcs-organizations-registry-common-service.wsdl
Надо собрать SOAP пакет из заголовка ISRequestHeader, тела exportOrgRegistryRequest. Посмотрим их в xsd схемах спецификаций по интеграций.

Ну приступим, откроем нужные нам пакеты XDTO. Оказывается, нужные сущности являются не типами, а свойствами, как с этим работать в документации на XDTO в статьях, которые я находил, не описано, поэтому воспользуемся урокам магии:

Начнем с тела exportOrgRegistryRequest.

Напишем функцию для сбора XML-запроса:

В итоге получим запрос:

Ответ от серверов ГИС ЖКХ (СИТ-1):

Как мы видим, ответ напрямую десериализовать не получится, потому что нет такого типа в предложенных xsd схемах. Нам надо как-то пропустить часть тэгов и обработать только область ответа. На эту тему я тоже не нашел информации, но методом проб и ошибок приходим к кусочку магий:

В итоге работать можно с очень сложными xsd схемами через стандартные инструменты платформы. В целом 1С контролируют типизацию и заполнения, бывает чересчур излишне, особенно когда внутри свойства пакета используется базовый тип другого пакета, но в любом случае тип нужно привести к локальному из-за другого пространства URI. Удобно работать с десериализоваными данными, так как там всю работу на себя берет платформа. Но проверки происходят на этапе выполнения, а при написания кода платформа 1С не предоставляет никаких подсказок и проходится пользоваться сторонними утилитами, и даже при выполнении большая часть элементов находится в состоянии «Неопределено» и даже тип или его свойство можно увидеть только в спецификации.

Итак. Мне принесли задание. Подружить 1С с внешним сервисом по приему отчетности в виде xml файла.

Сторонний сервис имеет свой API по приему файлов, на выходе выдает некий код «батч», по которому я смогу вызвать еще одну функцию и получить по этому батчу, всю развернутую информацию по ошибкам.

Файл схема xsd небольшая, но типов данных много, на основе этой схемы полностью сформированный XML файл занимает что-то около 200Мб.

Дали ссылку на сайт, где можно узнать все остальное. Показывать ссылку не имеет смысла, т.к. доступ только после авторизации.

В итоге я имел на руках некий файл с расширением «xsd».

На тот момент я даже понятия не имел, что это и с чем и как его едят.

Дали какие-то пароли, логины, ссылку, куда все это выкладывать, и дали срок 3 недели.

Очень помог Инфостарт (не без этого, конечно, – огромное спасибо).

Для начала ниже материал, которым я пользовался, пока не завершил этот мини проект, и поэтому вот ссылки вам в помощь, которые могут понадобиться в дальнейшем, я думаю, это «маст-хэйв» для тех, кто хочет обучиться правилам XDTO:

Есть файл с правилами, ниже показана картинка в компактном виде, весь xsd файл можно увидеть во вложении.

Рис.1

Скажу, что на момент, когда я получил данный файл, я мог кое-как создавать типы XDTO. Читал статью «XDTO это просто» (все три части, конечно, не всё вкурил, как без этого).
И в итоге умел примерно такое:

Рис.2

(вырезка из другого кода)

То есть я мог создать тип «объектXDTO, если этот тип был расположен в дереве импортированной схемы в ветке «Типы объектов».Но на рисунке 1 выше видно, что все важные данные создаются только через ветку «свойства».

Рис.3

К примеру, на рис.3 видно, что у свойства «FirstName» один параметр «Name» является типом, ссылка на которую уводит в ветку «Типы объектов», а уже таааам указывается, что это за тип и что он в себе еще дополнительно содержит.

Рис.4

Как быть?
Что делать?
Как их прочитать?
Как на их основе мне создать тип «ОбъектXDTO», ведь через создать запись можно только если записываемый/создаваемый тип является типом «ОбъектXDTO»?
Что только не приходилось делать… я же умел создавать и записывать значения только если требуемые расположены в ветке «Типы объектов».

В итоге.
В начале скажу, что у меня по условиям сбора данных есть некий первичный справочник список, в котором есть много реквизитов, которые необходимы для этого файла.
Данные собираются, фильтруются сортируются и в итоге я получаю готовую Таблицу значений.
Далее прохожу циклом эту таблицу и заполняю соответствующие реквизиты.

Итак, как я начал считывать XSD и создавать XML файлы.

Вначале считал пакет
Рис.5

Получил пакет в таком виде.
Рис.6

Далее мне нужно найти и спозиционироваться на свойстве «Records»

Вот она в дереве
Рис.7

Как это делается?
Скажу, что это как магия.
Пишем:
Рис.7

И мы получаем то значение, которое потом можем превратить в тип «ОбъектXDTO»

Рис.8

Получаем на выходе готовый нам нужный тип и делаем с ним все, что нужно.
К примеру, я должен пройтись циклом по реквизитам полученного объекта.

Просьба смотреть «не в воду», а в суть.

Тут главные строки это:

И т.д. далее, пока не получите что хотели.

Для получения каких-либо реквизитов свойства в схеме xsd пользуюсь такой конструкцией кода,

Но скажу, что видел и другие способы, тут, как говорится, дело ваше.

Результат рисунков с 7 по 12

Выглядит вот так в готовом файле:

И вот что я заметил (ну местные гуру, может, и знают давным-давно).

Это как бы и правила, и пометка.

Рассмотрим свойство «ContractCode»

Вот его описание:

Если это свойство имеет форму как «Элемент», то тогда код выглядит таким:

Т.е. я срази пишу значение в параметр, просто «= равно» и пошел.

Если свойство имеет форму как «Элемент», но он записан через знак «+»

То его код выглядит немного иначе

Т.е. нужно сначала создать через фабрику этот тип, получить его подчиненные подтипы и уже им присваивать значения из ваших данных.

И в итоге получается вот что.

Если в схеме это свойство имеет форму «элемент»

То в готовом файле запишется такая запись:

Т.е. все будет записано внутри т.н. «тегов».

Далее если вы имеете в схеме такую связку значений и ее свойства:

Т.е. у свойства «FundingType» есть подчиненный элемент «id», где его форма равна «Атрибут»

В этом случае код при написании НЕ изменится:

Замечу, что этот код похож на рис.16

Воот, а результат будет немножко другой:

Т.е. значение запишется сразу в сам «тег».

Есть такое свойство, как «Gender»

Он в свою очередь имеет ссылку на другой тип:

А вот сам тип «GenderType»

Вот его свойства:

Тут говорится, что данный тип значения в целом равен типу «string», но он вариант у него «атомарный», т.е. имеет, скажем, «перечисление». И его перечисления, это

Теперь дилемма, как мне его получить и как его записать.

Вот ответ (сам искал полдня):

Тут весь фокус в строке

Советую почитать про «Фасеты». Там все просто.

Ну и в завершение.

Собираем файл этими строками:

Тут лишь в конце стоит сказать один момент.

Принимающая сторона не передала значение «xmlns», пришлось ее искать и вписывать в начало файла, вот пример:

Читайте также:

  
• Как сделать развертку стен в автокаде
  
• Как именуются клетки таблицы ms excel
  
• Как вызвать такси драйвер
  
• Как сделать выпуклый текст в фотошопе
  
• Bat файл проверка запущена ли программа