8
</xsd:element>
- Вариант 2
При необходимости «разговорные» теги могут формироваться из подходящего комментария. В этом случае EDI-источник для соответствующего элемента должен документироваться с помощью соответствующего атрибута (см. также 6.9) или любого другого средства документирования.
Пример -
<xsd:element name ="M_ORDERS">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="din:Order_number"/>
<xsd:element ref="din:Order_date"/>
<xsd:element ref="din:Delivery_date"/>
<xsd:element ref="din:Buyer"/>
<xsd:element ref="din:Seller"/>
<xsd:element ref="din:Currency" minOccurs="0" maxOccurs="5"/>
<xsd:element ref="din:Line_item_details" minOccurs="1" maxOccurs="10"/>
<xsd:element ref="din:Total_order_value"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name ="Name">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base ="string1..10">
<xsd:attribute name="EDIPath" type="xsd:string" fixed="ORDERS.SG2.NAD.C080.3036(0120:040:01)"/>
<!- - The attribute EDIPath contains the reference to the original EDI standard - ->
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
- Принцип 2: Структура
- Одни и те же EDI-теги или имена должны формировать сгруппированные элементы (см. также принцип, описанный в 6.10).
- Если желательно разграничивать различные семантические элементы одного и того же контейнера данных, то для них необходимо использовать различные теги путем добавления суффикса к EDI-тегу или присваивать им различные имена.
- Схема может содержать дополнительные «сшитые» между собой элементы для групп сообщений или их обмена (сопоставимые с UN/EDIFACT UNG-UNE и UNB-UNZ).
- Любое использование EDI-контейнера данных (типа сообщения, группы сегментов, сегментов и т. п.) может представляться как независимый XML-элемент. Существующая EDI-структура является источником для XML-структуры, поэтому XML-схема должна обладать структурой, сопоставимой со структурой EDI MIG. Набор обобщенных XML-элементов не должен превышать набор EDI-элементов.
П р и м е ч а н и е — Способ, с помощью которого автор описывает MIG-инструкцию, должен отвечать требованиям соответствующего бизнес-процесса, поэтому и схема должна соответствующим образом структурироваться. Если, например, MIG-инструкция содержит "дату документа" и "запрашиваемую дату поставки" в двух различных экземплярах DTM-сегмента, то соответственно должны формироваться и раздельные XML-элементы. Кроме того, если они документируются в одном и том же экземпляре DTM-сегмента, то будет формироваться только один XML-элемент.