7
- Преобразование в поля в программах и неструктурированных файлах соответственно.
- Требования к принципам логического вывода схем
- MIG-техническая информация, перечисленная в разделе 4, при необходимости должна иметь возможность быть встроенной в схемы (структуры).
- Структура MIG-инструкции более низкого уровня должна быть легко доступной (XML- и традиционные EDI-инструкции должны быть сопоставимыми по структуре).
- Сформированные XML-сообщения должны иметь минимально возможную длину.
- Существование варианта, определенного с помощью настоящего стандарта как обязательного, при котором семантические данные могут представляться в XML виде.
- Разработчик MIG-инструкций решает, какие данные важны и какие структуры значимы для его конкретного приложения. Именно он должен определить, какие структурные элементы должны объединяться в схемы.
- Принципы формирования XML-схем, отбираемых из EDI MIG-инструкций
П р и м е ч а н и е — Область имен 'din' берется исключительно в справочных целях и поэтому может либо пропускаться, либо вместо нее можно использовать любую другую подходящую область имен.
- Принцип 1: Наименование тега
- Вариант 1
Имена XML-структуры должны формироваться из EDI-тегов, которые будут префиксами, зависящими от уровня структуры (группы сегментов, сегмента, составного элемента данных или самого элемента данных), т. е.:
,,M_"+ тип сообщения + [суффикс] Пример: M_ORDERS
,,G_"+ группа сегментов + [суффикс] Пример: G_SG36 или G_LIN_ALC
,,S_"+ сегмент + [ суффикс] Пример: S_LIN
,,C_"+ составной элемент данных + [суффикс] Пример: C_C082_2
,,D_"+ элемент данных + [суффикс] Пример: D_3035 или D_3035_10
Суффикс является дополнительным элементом и может формироваться с использованием различных семантических интерпретаций EDI-элементов.
Если XML-схемный файл формируется из EDIFACT MIG-инструкции, то необходимо указывать лишь префикс "D_'\ Поскольку в других EDI-стандартах должны использоваться иные префиксы, которые будут идентифицировать составные элементы данных и просто элементы данных путем применения цифровых тегов, то префиксы должны быть обязательными.
Второе представление тегов группы сегментов можно использовать в том случае, когда базовый EDI-стандарт не дает каких-либо конкретных групп сегментов или же всякий раз, когда желательно представление сегментов ряда операций. В последнем случае формирование вложения групп сегментов необходимо задавать как последовательность сегментов операций.
Рекомендации W3C XML предполагают использование "тегов, не требующих пояснений". EDI[FACT]-теги отвечают этим требованиям в большей степени, чем теги, записанные на естественном языке, поскольку для EDI-специалистов они представляют устоявшийся общепонятный смешанный язык из элементов романских, греческого и восточных языков.
Пример —
<xsd:element name ="M_ORDERS">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="din:D_1004"/>
<xsd:element ref="din:D_2380"/>
<xsd:element ref="din:D_2380_2"/>
<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>