Предисловие

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения»

Сведения о стандарте

1    ПОДГОТОВЛЕН Научно-техническим центром «ИНТЕК» на основе собственного аутентичного перевода на русский язык международного документа, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК100 «Стратегический и инновационный менеджмент»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 декабря 2011 г. № 1604-ст

4    Настоящий стандарт идентичен международному документу ИСО/ТС 20625:2002 «Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)» (ISO/TS 20625:2002 «Electronic data interchange for administration, commerce and transport (EDIFACT) — Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines»).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5    ВВЕДЕН ВПЕРВЫЕ

Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячно издаваемом информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет

©Стандартинформ, 2014

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

ГОСТ Р 54878-2011/ISO/TS 20625:2002

6.3.1    EDIFACT-сегмент, который содержит несколько элементов с коммерческой информацией, обладает обобщающей функцией. Если же этот сегмент содержит только один элемент с коммерческой информацией, то он этой функцией не обладает и при преобразовании в XSD-схему данный уровень сегмента может выпадать.

6.3.2    Элементы основного стандарта, не используемые в MIG-инструкции, будут исключаться.

6.3.3    Постоянные префиксы или коды не переходят в XML-структуру (для определенного элемента данных только один код будет документироваться в MIG-инструкции). Соответствующие элементы данных не должны переходить в XML-структуру.

Ниже приведено несколько примеров.

Получено из:

<xsd:element name =”S_DTM”>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:C_C507″/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name =”C_C507″>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:D_2005″/>

<xsd:element ref=”din:D_2380″/>

<xsd:element ref=”din:D_2379″/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name =”D_2379″ fixed =”1027>

<xsd:element name =”D_2005″ fixed =”4″/>

<xsd:element name =”D_2380″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Orderdate</xsd:documentation>

</xsd:annotation>

</xsd:element>

Этот принцип дает:

<xsd:element name =”D_2380″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Orderdate</xsd:documentation>

</xsd:annotation>

</xsd:element>

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

6.4 Принцип 4: Состояние

EDI-состояние и прикладной статус в MIG-инструкции будут объединены в XML-состоянии (с поддержанием больших ограничений).

Состояние “обязательное” будет представляться с помощью минимально повторяющегося индекса “1”, а состояние “условное” — с помощью минимально повторяющегося индекса “0”. Состояние задается атрибутом minOccurs.

Пример —

Состояние “условное”:

Группа сегментов Сегмент

Составной элемент данных

Элемент данных

7

<xsd:element ref=”din:G_LIN” minOccurs=”1″ maxOccurs=”10″/> <xsd:element ref=”din:S_LIN” minOccurs=”1″ maxOccurs=”1″/> <xsd:element ref=”din:C_C516″ minOccurs=”1″ maxOccurs=”1″/>

<xsd:element ref=”din:D_0065″ minOccurs=”1″ maxOccurs=”1″/>

6.5 Принцип 5: Максимальное число экземпляров

Число экземпляров MIG-инструкции формирует число XML-экземпляров. Это значение будет задаваться с помощью XSD-атрибута maxOccurs.

Пример —

Группа    <xsd:element ref=”din:G_SG25″ minOccurs=”1″ maxOccurs=”10″/>

сегментов

Сегмент <xsd:element ref=”din:S LIN” minOccurs=”1″ maxOccurs=”1 “!>

При использовании версии 4 EDIFACT-синтаксиса (см. ИСО 9735-1) и соответствующих каталогов этот принцип применим и к составным элементам данных, и к элементам данных.

6.6    Принцип 6: Форматы элементов данных

6.6.1    Обозначения “ап” и “а” относятся к формату представления данных “строка”, а обозначение “п” — к формату представления данных “десятичный”. Для длин буквенно-символьных и цифровых элементов данных, как это определено в MIG-инструкции, будет формироваться соответствующий атрибут simpleTypes.

6.6.2    Форматы представления даты могут передаваться в XML-типы данных “date”, “timelnstant” и “time”. В этом случае необходимо использовать преобразование форматов, имеющих следующее представление в XML:

date (дата):    1999-05-31    (согласно ИСО    8601)

time (время):    13:20:00

timelnstant (момент времени): 1999-05-31Т13:20:00

Пример —

<xsd:simpleType name= “stringl.. 70”>

<xsdrestriction base= “xsd:string ’>

<xsd:minLength value=”1″/>

<xsd:maxLength value=”70″/>

</xsd:restriction>

</xsd:simpleType>

6.7    Принцип 7: Перечни кодов и задаваемые пользователем коды

6.7.1    Кодированные элементы данных должны определяться как данные комплексного типа. Если в MIG-инструкции задокументированы только специальные коды элементов данных, то именно эти коды станут допустимыми для приложений и будут передаваться в XML-структуру.

6.7.2    Если в MIG-инструкции для элементов данных коды не предусмотрены, то допускается наличие перечня всех имеющихся кодов, который будет передаваться в XML-структуру.

6.7.3    Перечни многократно используемых кодов могут предоставляться с помощью внешних файлов.

6.7.4    Наименования кодов будут дополнительно сохраняться в виде аннотаций к ним.

6.7.5    Согласно принципу 3 (см. 6.3) постоянные префиксы или коды не должны передаваться в XML-струкгуру (только один определенный элемент данных документируется в MIG-инструкции). Соответствующие элементы данных не должны предусматриваться в XML-струкгуре, однако в случае острой необходимости в использовании какого-либо элемента данных его необходимо включать в XML-структуру (например, вид валюты, соответствующий элементу данных 6345 в сегменте МОА).

Примеры —

(1)

<xsd:element name =”D_6345″ type =’D_6345’7>

<xsd:simpleType name=”D_6345″>

<xsd:restriction base=”xsd:string”>

<xsd:enumeration value=’DEM’>

8

<xsd:annota tion >

<xsd:documentation>Deutsche Mark</xsd:documentation> </xsd:annotation>

</xsd:en umera tion >

<xsd:enumeration value=”EUR”>

<xsd:annota tion >

<xsd:documentation>Euro</xsd:documentation>

</xsd:annotation>

</xsd:en umera tion >

<xsd:enumeration vaiue=”GBP”>

<xsd:annota tion >

<xsd:documentation>PfundSterling</xsd:documentation>

</xsd:annotation>

</xsd:en umera tion >

</xsd:restriction>

</xsd:simple Type>

(2)

<xsd:simpleType name=”D_6347″>

<xsd-.restriction base= “xsd:string “> <xsd:enumeration value=”1″/> <xsd:enumeration value=”2″/> <xsd:enumeration vaiue=”3″f> <xsd:enumeration value=”4″/> <xsd:enumeration value=”5″/> <xsd:enumeration value=”6″/> <xsd:enumeration value=”7″/>

… etc. listing of the complete code list </xsd:simple Type>

(3)

<?xml version=”1.0″?>

<xsd:schema targetNamespace= “http://www. din. de/example/orders ” xmlns:din= “http://www.din.de/example/orders ” xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”> <include schemaLocation= “CL_6411.xsd”/>

<xsd:element name =”D_6411″ type =”din:CL_6411″>

<xsd:annotation>

<xsd:documentation>Measure unit</xsd:documentation> </xsd:annotation>

</xsd:element>

External file with codes:

<?xml version=”1.0″?>

<xsd:schema targetNamespace=”http://www.din.de/ example/orders” xmlns:din=”http://www.din.de/ example/orders” xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”> <xsd:simpleType name=”CL_6411″>

<xsd-.restriction base= “xsd:string “>

<xsd:enumeration value=”ACR”/>

<xsd:enumeration value=”AMH”/>

(4)

<xsd:simpleType name=”CL_6411″>

<xsd-.restriction base= “xsd:string “>

<xsd:enumeration value=”TNE”>

<xsd:annota tion >

<xsd:documentation>Tonne (1000 kg) *</xsd:documentation> </xsd:annotation>

</xsd:en umera tion >

<xsd:enumeration value=”KGM”>

<xsd:annotation>

<xsd:documentation>Kilogram *</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value=”GRM”>

<xsd:annotation>

<xsd:documentation>Gram *</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value=”DZN”>

<xsd:annotation>

<xsd:documentation>Dozen</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

(5)

<xsd:element name =”D_6345″ type =”din:D_6345″/>

<xsd:simpleType name= ”D_6345″>

<xsd:restriction base= “xsd:string “>

<xsd:en umera tion value=”DEM”>

<xsd:annotation>

<xsd:documentation>Deutsche Mark</xsd:documentation> </xsd:annotation>

</xsd:en umera tion >

</xsd:restriction>

</xsd:simple Type>

6.8 Принцип 8: Имена EDI-объектов

6.8.1    Стандартизованные или присваиваемые пользователем имена групп сегментов, сегментов, составных элементов данных и элементов данных могут предусматриваться в схеме как атрибут “annotation”. В качестве атрибута для любого XML-элемента допускается использовать только одно EDI-имя.

6.8.2    Если ED-объект имеет стандартизованное или присвоенное пользователем имя, сохраняется только последнее.

Примечание — Последнее утверждение относится к имени объекта, которое может находиться по присвоенному пользователем имени, BSU или другим образом в MIG-инструкциях. При этом XML-файл будет оставаться незаполненным, а логическое преобразование — легко реализуемым с помощью синтаксического анализатора.

Примеры –

(V

<xsd:element name =”S_DTM”>

<xsd:annotation>

<xsd:documentation>Date/Time/Period</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:D 2005″/> …

<xsd:element name =”S_DTM”>

<xsd:annotation>

<xsd:documentation>Order or delivery date </xsd:documentation> </xsd:annotation>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:D 2005″/> …

ГОСТ Р 54878-2011/ISO/TS 20625:2002

6.9    Принцип 9: Размещение данных

6.9.1    Поскольку MIG-инструкция содержит подробное описание размещения данных, то в качестве атрибутов могут формироваться «точки привязки», которые будут позволять применять XML-формат обмена данными KEDI-подсистемам.

6.9.2    С помощью атрибута EDISource предусмотрен EDI[FACT]-hcto4HHK. Это обозначение атрибута сочетает в себе функциональное назначение применяемого документирования и основную информацию относительно версии каталога, например EDIFACT-каталога.

При этом применимы следующие правила:

–    путь указывается в форме “segmentgroup.segment.compositedataelement.dataelement” или “segmentgroup.segment.dataelement”;

–    группа сегментов может оказаться многочисленной для указания уровней EDIIFACTI-структуры;

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

В конце порядкового номера сегмента, приведенного в исходном типе EDIFACT-сообщения, необходимо также добавлять порядковый номер элемента данных (составного или простого) в соответствующий сегмент после двоеточия и при необходимости — порядковый номер компонента в составном элементе данных.

Например, запись вида (0120:020:02) должна читаться следующим образом: “Порядковый номер в стандарте”: “порядковый номер составного элемента данных или элемента данных”: “при необходимости — порядковый номер компонента в составном элементе данных”.

Примеры —

(1)

<xsd:element name =”D_3433″>

<xsd:annotation>

<xsd:documentation>BIC of buyer’s bank</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base =”xsd:decimar>

<xsd:attribute    name= ‘Mappinganchor” type= “xsd:string “

use= “fixed “value= “BIC-BB “/>

</xsd:extension >

</xsd:simple Conten t>

</xsd:complexType>

</xsd:element>

(2)

<xsd:element name =”D_3433″>

<xsd:annotation>

<xsd:documentation>BIC of buyer’s bank</xsd:documentation>

</xsd:annotation>

<xsd:complexType>

<xsd:simpleContent>

<xsd:extension base =”xsd:decimar>

<xsd:attribute name=”EDIPath” type=”xsd:string^H use=^Hfixed^H value=”SG2[NAD.3035=BY].FII.C088.3433(0140:030:01)”/>

</xsd:extension >

</xsd:simple Conten t>

</xsd:complexType>

</xsd:element>

6.10    Принцип 10: Группирование контейнеров данных с одинаковыми именами

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

11

ГОСТ Р 54878-2011/ISO/TS 20625:2002

6.10.1    Структура

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

6.10.2    Состояние

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

Пример — ORDERS DTM 2379 состояние: R, IFTMIN DTM 2379 состояние: О

>    XML состояние: О

6.10.3    Формат

Формат должен определяться в соответствии с широко используемым форматом, указанным в MIG-инструкции (инструкциях).

Пример — ORDERS DTM 2380 формат: п8, IFTMIN DTM 2380 формат: ап..35

>    XML формат: строка 1 ..35

6.10.4    Перечень кодов

Для каждого кодированного элемента данных необходимо формировать сгруппированный перечень кодов, содержащий все коды, применимые согласно MIG-инструкции (инструкциям).

Пример — ORDERS DTM 2380 перечень кодов: 102;103, IFTMIN DTM 2380 перечень кодов: 103;203

>    XML перечень кодов: 102;103;203

12

ГОСТ Р 54878-2011/ISO/TS 20625:2002

Приложение А (справочное)

Пример преобразования данных из EDIFACT в XML

Примечание — Приведенные в данном приложении примеры основаны на использовании тегов, выраженных на немецком языке, однако не исключено и использование для них и других языков. Состояние, обозначаемое буквой R, означает “требуемое”, а состояние, обозначаемое буквой О, означает “свободное, опционное”. Оба эти состояния имеют тот же смысл, что и состояние, обозначаемое буквами М (“обязательное”) и С (“условное”). Состояние, обозначаемое буквой N, означает, что оно “не используется”.

А.1 Структура для преобразования данных, основанная на EDIFACT А.1.1 Общие положения

Основой для формирования XML-структуры является применение в EDIFACT сообщения типа ORDERS (Заказ на покупку) со следующими особенностями:

А.1.2 Структура сообщения А.1.2.1 Таблица сегментов

Таблица А.1 — Таблица сегментов для EDIFACT-сообщений типа ORDERS

№ Тег Состояние Реп Содержание 01 UNH М 1 Заголовок сообщения 02 BGM М 1 Тип документа и его номер 03 DTM м 1 Дата заказа 04 DTM м 1 Дата поставки SG2 R 1 Покупатель 05 NAD м 1 Идентификационные данные покупателя 06 FII 0 1 Информация о банковском счете покупателя SG3 о 1 Сумма НДС для покупателя 07 RFF м 1 Сумма НДС SG5 о 1 Контактная информация о покупателе 08 СТА м 1 Ответственный представитель покупателя 09 СОМ о 1 Номер телефона 10 СОМ о 1 Резервные контактные данные SG2 R 1 Продавец 11 NAD М 1 Идентификационные данные продавца

13

ГОСТ Р 54878-2011/ISO/TS 20625:2002

Содержание

1    Область применения………………………………… 1

2    Нормативные ссылки………………………………… 1

3    Термины, определения и сокращения…………………………. 1

4    Стандартное содержание инструкций по реализации сообщений (MIG)…………… 2

5    Требования к принципам логического вывода схем…………………… 3

6    Принципы формирования XML-схем, отбираемых    из EDI    MIG-инструкций………….. 3

Приложение А (справочное) Пример преобразования данных из EDIFACT в XML………. 13

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской    Федерации…………….. 43

Библиография…………………………………….. 44

Введение

В традиционных EDI-стандартах приводится синтаксис для применения контентов данных в различных видах коммерческой деятельности путем использования элементов данных, сегментов и типов сообщений. Первоначально XML-язык определял другой синтаксис, который в случае переработки программ EDI приводил к огромным дополнительным затратам, тем самым препятствуя достижению исходно поставленной задачи — привлечению к электронным бизнес-процессам мелких и средних предприятий (SME).

В настоящем стандарте описан способ применения XML-синтаксиса при использовании технологии EDI. Пользователям XML-языка при этом станет легче и удобнее применять EDI-данные, получаемые из существующих приложений.

EDIFACT-инструкции по реализации сообщений (MIGs) описывают процедуры применения стандартизированных типов EDIFACT-сообщений к бизнес-процессам, вследствие этого они являются удобным инструментом для формирования XML-схем (структур). Настоящий стандарт устанавливает процесс перевода данных.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЭЛЕКТРОННЫЙ ОБМЕН ДАННЫМИ В УПРАВЛЕНИИ, ТОРГОВЛЕ И НА ТРАНСПОРТЕ (EDIFACT)

Принципы формирования файлов XML схемы (XSD) на основе инструкций по реализации EDI(FACT)

Electronic data interchange for administration, commerce and transport (EDIFACT).

Rules for generation of XML scheme files (XSD) on the basis of EDI(FACT) implementation guidelines

Дата введения —2012 — 09 — 01

1    Область применения

Настоящий стандарт устанавливает принципы выбора XML-схем (структур) из EDI MIG-инструкций, обеспечивающих применение обоснованного метода представления семантических данных.

В настоящем стандарте определен способ выбора XML-данных из UN/EDIFACT MIG-инструкций. Рассматриваемые принципы применимы и кдругим EDI-стандартам.

Настоящий стандарт не распространяется на описания типов документов (DTDs).

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты (для датированных ссылок следует использовать только указанное издание, для недатированных ссылок следует использовать последнее издание указанного документа):

ИСО 8601:2004 Элементы данных и форматы для обмена информацией. Обмен информацией. Представление дат и времени (ISO 8601:2004, Data elements and interchange formats. Information interchange. Representation of dates and times)

ИСО 9735-1:2002 Электронный обмен данными в управлении, торговле и на транспорте (EDIFACT). Синтаксические правила для прикладного уровня (версия 4, редакция 1). Часть 1. Синтаксические правила, общие для всех частей (ISO 9735-1:2002, Electronic data interchange for administration, commerce and transport (EDIFACT). Application level syntax rules (Syntax version number: 4, Syntax release number: 1). Part 1. Syntax rules common to all parts)

3    Термины, определения и сокращения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1    базовый семантический регистр (basic semantics register; BSR).

3.2    базовая семантическая единица (basic semantic unit; BSU).

3.3    описание типа документа (document type definition; DTD).

3.4    электронный обмен данными (electronic data interchange; EDI).

3.5    электронный обмен данными в управлении, торговле и на транспорте (electronic data interchange for administration, commerce and transport; EDIFACT).

3.6    гипертекстовый язык разметки документов (hyper text mark-up language; HTML).

3.7    инструкция по реализации сообщения (message implementation guideline; MIG).

3.8    стандартный обобщенный язык описания документов (standard generalised mark-up language; SGML).

Издание официальное

3.9    расширяемый язык описания связей (extensible link language; XLL).

3.10    расширяемый язык разметки (extensible mark-up language; XML).

3.11    расширяемое определение схемы (extensible schema definition; XSD).

3.12    расширяемый язык таблиц стилей (extensible stylesheet language; XSL).

3.13    www-консорциум (world wide web consortium; W3C).

3.14    элемент (element): Синтаксический структурный блок, содержащий данные и/или атрибуты.

3.15    имя (name): Имя в XML-языке начинается с буквы или допустимого специального символа, далее могут следовать буквы, цифры, дефисы, подчеркивания, двоеточия или точки. Имена, начинающиеся с «xml» или со строки символов, которые примыкают к ((‘X’l’x’) (‘M’l’m’) (’L’|T)), являются резервными для целей XML-стандартизации.

3.16    шаблон (template): Предварительно задаваемая эталонная структура, сравниваемая с полной структурной единицей (или с одной из ее частей), которая должна быть распознана.

3.17    тег, метка (tag): Инструкция по форматированию или семантическая пометка.

4 Стандартное содержание инструкций по реализации сообщений (MIG)

4.1    Уровень: MIG

a)    Идентификационные данные MIG-инструкции.

b)    Идентификационные данные служебного EDIFACT-каталога.

c)    Идентификационные данные типа сообщения и при необходимости промышленных подгрупп.

4.2    Уровень: Тип сообщения

a)    Структура типа сообщения (сегменты и группы сегментов) и идентификационные данные их используемых частей.

b)    Состояние (стандартное или прикладное) используемых сегментов и групп сегментов.

c)    Контекстно связанные имена и описания сегментов и групп сегментов.

d)    Примеры.

e)    Взаимосвязи между сегментами и группами сегментов.

f)    Дополнительный текст, комментарии относительно уровня типа сообщения.

4.3    Уровень: Сегменты и составные элементы данных

a)    Структура сегментов и составных элементов данных, а также указание используемых ими позиций.

b)    Состояние (стандартное или прикладное) элементов данных и составных элементов данных.

c)    Взаимосвязи между элементами данных и составными элементами данных в одном типе сообщений.

d)    Контекстно связанные имена и описания.

e)    Примеры.

^Дополнительный текст, комментарии.

4.4    Уровень: Элемент данных

a)    Характеристики EDI-элементов данных (тип, длина) и ограничения на их применение, основанные на MIG-инструкциях и контекстно связанном исполнении.

b)    Контекстно связанные имена и описания элементов данных и при необходимости индивидуальные теги и описания, например, отбираемые из хранилищ данных типа ISO-BSR.

c)    Примеры.

d)    Дополнительный текст, комментарии.

e)    Допустимые значения.

f)    Константы.

д) Четко задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодов.

h)    Четко задаваемые пользователем коды.

i)    Произвольно задаваемые пользователем EDIFACT-коды или перечни ISO/UN-кодов.

j)    Произвольно задаваемые пользователем коды, не содержащиеся в каталоге EDIFACT-кодов.

k)    Принципы, которым должны отвечать значения элементов данных.

l)    Преобразование в поля в программах и неструктурированных файлах соответственно.

2

ГОСТ Р 54878-2011/ISO/TS 20625:2002

5    Требования к принципам логического вывода схем

a)    MIG-техническая информация, перечисленная в разделе 4, при необходимости должна иметь возможность быть встроенной в схемы (структуры).

b)    Структура MIG-инструкции более низкого уровня должна быть легкодоступной (XML- и традиционные EDI-инструкции должны быть сопоставимыми по структуре).

c)    Сформированные XML-сообщения должны иметь минимально возможную длину.

d)    Существование варианта, определенного с помощью настоящего стандарта как обязательного, при котором семантические данные могут представляться в XML виде.

e)    Разработчик MIG-инструкций решает, какие данные важны и какие структуры значимы для его конкретного приложения. Именно он должен определить, какие структурные элементы должны объединяться в схемы.

6    Принципы формирования XML-схем, отбираемых из EDI MIG-инструкций

Примечание — Область имен ‘din’ берется исключительно в справочных целях и поэтому может либо пропускаться, либо вместо нее можно использовать любую другую подходящую область имен.

6.1    Принцип 1: Наименование тега

6.1.1    Вариант 1

Имена XML-структуры должны формироваться из EDI-тегов, которые будут префиксами, зависящими от уровня структуры (группы сегментов, сегмента, составного элемента данных или самого элемента данных), т. е.:

„М_”+ тип сообщения + [суффикс]    Пример:    M    ORDERS

,,G_”+ группа сегментов + [суффикс]    Пример:    G_SG36    или    G    LIN    ALC

,,S_”+ сегмент + [суффикс]    Пример:    SLIN

„С_”+ составной элемент данных + [суффикс]    Пример:    С_С082_2

,,D_”+ элемент данных + [суффикс]    Пример: D_3035 или D303510

Суффикс является дополнительным элементом и может формироваться с использованием различных семантических интерпретаций EDI-элементов.

Если XML-схемный файл формируется из EDIFACT MIG-инструкции, то необходимо указывать лишь префикс “D_”. Поскольку в других ЕDl-стандартах должны использоваться иные префиксы, которые будут идентифицировать составные элементы данных и просто элементы данных путем применения цифровых тегов, то префиксы должны быть обязательными.

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

Рекомендации W3C XML предполагают использование “тегов, не требующих пояснений”. EDI[FACT]-Tern отвечают этим требованиям в большей степени, чем теги, записанные на естественном языке, поскольку для EDI-специалистов они представляют устоявшийся общепонятный смешанный язык из элементов романских, греческого и восточных языков.

Пример —

<xsd:element name =”M_ORDERS”>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref= “din:D_1004 “/>

<xsd:element ref= “din:D_2380 ”t>

<xsd:element ref= “din:D_2380_2 ”t>

<xsd:element ref=”din:G_SG2″/>

<xsd:element ref= “din:G_SG2_2 “/>

<xsd:element ref=”din:D_6345″ minOccurs=”0″ maxOccurs=”5″/>

<xsd:element ref=”din:G_SG25″ minOccurs=”1″ maxOccurs=”10″/>

<xsd:element ref= “din:D_5004_2 “/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

3

6.1.2    Вариант 2

При необходимости «разговорные» теги могут формироваться из подходящего комментария. В этом случае EDI-источник для соответствующего элемента должен документироваться с помощью соответствующего атрибута (см. также 6.9) или любого другого средства документирования.

Пример –

<xsd:element пате = “M ORDERS “>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref= “din:Order_number”/>

<xsd:element ref= “din:Order_date “f>

<xsd:element ref= “din:Delivery_date “f>

<xsd:element ref=”din:Buyer”/>

<xsd:element ref=”din:Seiier”/>

<xsd:element ref=”din:Currency” minOccurs=”0″ maxOccurs=”5″/>

<xsd:element ref=”din:Une_item_details” minOccurs=”1″ maxOccurs=”10″/>

<xsd:element ref= “din: Total_order_vaiue 7>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name =’Name”>

<xsd:complexType>

<xsd:simpleContent>

<xsdextension base =’string1..10’>

<xsd:attribute name=’EDIPath” type=’xsd:string” fixed= “ORDERS. SG2. NA D. C080.3036(0120:040:01)”/>

<!- – The attribute EDIPath contains the reference to the original EDI standard – ->

</xsd^extension >

</xsd:simpleContent>

</xsd:complexType>

</xsd:element>

6.2    Принцип 2: Структура

6.2.1    Одни и те же EDI-теги или имена должны формировать сгруппированные элементы (см. также принцип, описанный в 6.10).

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

6.2.3    Схема может содержать дополнительные «сшитые» между собой элементы для групп сообщений или их обмена (сопоставимые с UN/EDIFACT UNG-UNE и UNB-UNZ).

6.2.4    Любое использование EDI-контейнера данных (типа сообщения, группы сегментов, сегментов и т. п.) может представляться как независимый XML-элемент. Существующая EDI-структура является источником для XML-структуры, поэтому XML-схема должна обладать структурой, сопоставимой со структурой EDI MIG. Набор обобщенных XML-элементов не должен превышать набор EDI-элементов.

Примечание — Способ, с помощью которого автор описывает MIG-инструкцию, должен отвечать требованиям соответствующего бизнес-процесса, поэтому и схема должна соответствующим образом структурироваться. Если, например, MIG-инструкция содержит “дату документа” и “запрашиваемую дату поставки” в двух различных экземплярах DTM-сегмента, то соответственно должны формироваться и раздельные XML-элементы. Кроме того, если они документируются в одном и том же экземпляре DTM-сегмента, то будет формироваться только один XML-элемент.

4

ГОСТ Р 54878-2011/ISO/TS 20625:2002

Несколько поясняющих примеров для 6.2.1 и 6.2.2:

Вариант 1: Инструкция содержит два DTM-сегмента (см. рисунок 1).

DTM (#1), Status М, Occurrence 1, Qualifier in DE 2005: 4, Name: Order date DTM (#2), Status M, Occurrence 1, Qualifier in DE 2005: 2, Name: Requested delivery date Рисунок 1 — Диаграмма сообщения для инструкции, содержащей два DTM-сегмента

Установленный по умолчанию переход в XML-схему в соответствии с 6.2.1 таков:

<xsd:element name =”S_DTM”>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:D_2005″/>

<xsd:element ref=”din:D_2380″/>

</xsd:sequence>

</xsd:complexType>

<xsd:element name =”D_2005″ type =”din:D_2005″>

<xsd:annotation>

<xsd:documentation>Typeof date</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name =”D_2380″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Date/Time/Period</xsd:documentation>

</xsd:annotation>

</xsd:element>

Примечание — Элемент D_2005 принадлежит к перечислимому типу данных и содержит две положительные величины ‘2’ и ‘4’.

В другом варианте применение принципа 6.2.2 дает следующий результат:

<xsd:element name =”D_2380″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Orderdate</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name =”D_2380_2″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Delivery date</xsd:documentation>

</xsd:annotation>

</xsd:element>

или

<xsd:element name =”Order_date” type =”xsd:decimal”/>

<xsd:element name =”Delivery_date” type =”xsd:decimal”/>

5

Вариант 2: Инструкция с неявно документированной датой, использующая только один DTM-сегмент (см. рисунок 2).

DTM, Status М, Occurrence 2, Qualifier in DE 2005: 2 и 4 Рисунок 2 — Диаграмма сообщения для инструкции, содержащей только один DTM-сегмент

Преобразование в XML-схему аналогично преобразованию, применяемому по умолчанию в соответствии с принципом 6.2.1, т. е.:

<xsd:element name =”S_DTM”>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”din:D_20057>

<xsd:element ref=”din:D_23807>

</xsd:sequence>

</xsd:complexType>

<xsd:element name =”D_2005″ type =”din:D_2005″>

<xsd:annotation>

<xsd:documentation>Type ofdate</xsd:documentation>

</xsd:annotation>

</xsd:element>

<xsd:element name =”D_2380″ type =”xsd:decimal”>

<xsd:annotation>

<xsd:documentation>Orderdate</xsd:documentation>

</xsd:annotation>

</xsd:element>

Поясняющий пример для 6.2.3:

<xsd:schemaxmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<xsd:element name =”S_UNB”>

<xsd:complexType>

<xsd:sequence>

<xsd:element ref=”D_0004″ minOccurs=”0″ maxOccurs-T’/>

<xsd:element ref=”D_0010″ minOccurs=”0″ maxOccurs=”17>

<xsd:element ref=”D_0017″ minOccurs=”0″ maxOccurs-T’/>

<xsd:element ref=”D_0020″ minOccurs=”0″ maxOccurs=”1″/>

<xsd:element ref=”M_ORDERS” minOccurs=”1″ maxOccurs=”unbounded”/>

</xsd:sequence>

6.3 Принцип 3: Оптимизация структуры

Если главный интерес представляют одноуровневые XML-струкгуры, то применение нижеследующих принципов будет приводить к получению оптимизированных результатов, однако для их интеграции в существующие системы необходимо соблюдать минимальные требования к структуре данных, устанавливаемые применяемой EDI-системой.

6