Рекомендации участникам
Для участников, ранее реализовавших текущий ("старый") формат, ниже даются комментарии по поводу основных отличий форматов. Ознакомление
с данными комментариями позволит облегчить процесс перевода разработанных ранее систем на новый формат сообщений.
Отличия форматов
Справочники
В старом формате все ограничения на значения тех или иных элементов указывались непосредственно в файле схемы формата. Это делалось путём явного
указания ограничений на формат или набор значений. Такой подход облегчает валидацию сообщений стандартными средствами.
В новом формате большинство информации об ограничениях вынесено во внешние справочники и описания форматов. Все скалярные типы, для которых необходимо
указать ограничение на формат или набор значений, являются наследниками типа Scheme. Для каждого такого типа
указывается атрибут (название атрибута разное для разных типов), в значении которого указывается гиперссылка на страницу, где описывается формат/справочник.
Так, например, тип PartyRole расширяет тип Scheme следующим образом:
<xsd:extension base="Scheme">
<xsd:attribute name="partyRoleScheme"
type="xsd:anyURI"
default="http://repository.nsd.ru/taxonomy/cs/party-role">
</xsd:attribute>
</xsd:extension>
Атрибут partyRoleScheme задаёт ссылку на описание формата/справочника, при этом его указание в явном виде в конкретном
xml-сообщении необязательно, так как у него указано значение по умолчанию default="http://repository.nsd.ru/taxonomy/cs/party-role".
Использование внешних справочников усложняет процедуру валидации сообщений, так как её уже невозможно сделать только стандартными средствами. Однако плюсом
такого подходя является возможность модифицировать только справочники, не обновляя версию схемы.
Переиспользование элементов
Сообщения старого формата несколько удобнее "читать глазами" ввиду того, что необходимые блоки всегда описываются в том месте сообщения, где они понадобились. Так, например,
если в каком-либо блоке сообщение требуется привести информацию об участнике, то воспроизводится весь блок, описывающий такую информацию:
<PARTY>
<id_2>
<id>RZ0002500004</id>
<id_type>RPZR</id_type>
</id_2>
<name>ЮЛ клиент 4</name>
</PARTY>
В новом формате применяется подход, при котором информация, которую можно переиспользовать описывается в документе(сообщении) один раз. У корневого элемента соответствующего
блока указывается атрибут @id. После чего в любом месте сообщения, где необходимо привести такую информацию, вместо воспроизведения
всего блока приводится лишь ссылка на уже описанный блок.
Пример описания информации об участнике с указанием атрибута id, на который в дальнейшем будет даваться ссылка:
<party id="Party1">
<partyId>RZ0002500003</partyId>
<partyName>ЮЛ клиент 3</partyName>
<relatedParty>
<partyReference href="Party1"/>
<role>BaseReportingAgent</role>
<type>AllPositions</type>
</relatedParty>
</party>
Пример ссылки на блок с описанием участника:
<partyReference href='Party1'>
Такой подход потенциально снижает размер сообщений за счёт переиспользования информации.
Типизация сообщений
В старом формате построение сообщений шло от финансового инструмента, информация связанная с которым передавалась. Так, например, сообщения, связанные с валютным свопом,
имели корневой элемент, начинающийся с подстроки SWAPCURRENCY_. Далее, в зависимости от назначения сообщения к имени корневого элемента
добавлялось окончание. Кроме того, элемент <msgAction> сообщения уточнял назначение сообщения.
В новом формате построение сообщений идёт не от инструмента, а от набора типовых сообщений. Так, например, сообщение nonpublicExecutionReport
используется для подачи в репозитарий запроса на регистрацию сделки, внесение изменений, регистрации прекращения сделки. При этом информация о конкретном инструменте
находится внутри сообщения и никак не обозначается в названии корневого элемента.