А.Календарев
Введение в XML/EDI
Исторически так сложилось, что основная масса заключенных
сделок оформлялась на бумаге. Условия сделки письменно излагались и
договаривающие стороны под условиями ставили свои подписи. В конце XVII века
были уже сформированы основные требования к составлению разных видов документов,
такие как купчая, дарственная, наследство и т.д.
Сегодня, в сфере бизнеса создается и обрабатывается
внушительный объем разнообразной бумажной документации. Она включает в себя
заказы на приобретение, счета, каталоги, отчеты, платежные поручения и т.д.
Бурное развитие телекоммуникаций в конце 80-х годов XX века открыло ворота для
электронной торговли и Электронного обмена данными (Electronic Data Interchange
или EDI)
Идея систем EDI заключается в стандартизации документов и
представлении их в виде, удобном для компьютерной обработки. В этом
заинтересованы все участники внешнеэкономической деятельности, в том числе и
контролирующие органы (таможня, налоговая служба).
Коренное отличие систем EDI от систем электронного
документооборота состоит в том, что EDI системы - это межведомственные системы
обмена (подачи) электронными документами, использующие строго
стандартизированные правила составления электронных документов. А система
электронного документооборота - это системы, как правило, разрабатываемые в
рамках одной корпорации или предприятия, обмен в которых осуществляется по
средствам распределенных СУБД (RMDB).
Бурное развитие Internet-технологий за последнее пятилетие
вовлекло в международную электронную паутину миллионы новых пользователей.
Требования к цифровому обмену возросли, и уже существующие EDI системы перестали
удовлетворять многие группы пользователей.
Современные приложения требуют более гибкий протокол
представления данных и механизмы, позволяющие определять структуру документа и
описывать содержащие в нем элементы. Данным требованием удовлетворяет язык
расширенной разметки - XML ("Extensible Markup Language"),
спецификация которого была утверждена международной организацией я W3C в начале
февраля 1998 г.
Сегодня создаются новые языки, в том числе и для ведения
электронной коммерции, созданные на основе XML. В настоящее время разработана
спецификация OTP - Открытого торгового протокола (Online Trading Protocol),
являющейся спецификацией деловых транзакций на основе XML. Компаниями CheckFree,
Intuil и Microsoft разработан язык OFX, позволяющий на основе XML безопасно
проводить в WEB финансовые транзакции - Open Financial eXchange.
Основная идея создания XML/EDI систем заключается в
дополнительном привлечение в электронную торговлю мелких и средних клиентов.
Существующие сегодня EDI системы довольно дороги (от 10 до 100 тыс. дол. США) и
многим мелким конечным пользователем, в связи с этим, недоступны.
Одноступенчатое формирование XML-документа
Развитие новых тенденций объединения технологий XML и EDI
обеспечивает динамичный процесс формирования электронных документов и
взаимодействия между информационными системами. Тенденция объединения XML и EDI
является наиболее перспективным направлениям в использование электронных
документов.
Рис. 1
На рис.1 представлена схема вариантов обмена Электронными
документами для разных (мелких и крупных) компаний. Крупные компании продолжают
использовать уже имеющие EDI-системы через VAN сеть (сеть с добавленной
стоимостью, т.е. предоставление за плату добавочных услуг). Провайдеры
предоставляют такую услугу, как подготовка и обмен EDI-сообщениями по средствам
корпоративных сетей. Более мелкие компании, используя технологию XML/EDI
осуществляют обмен через Internet.
Один из самых простых вариантов обмена используя XML/EDI
технологию - это подготовка XML-докуамента на стороне клиента и отправка на
XML-сервер компании, где документ проверяется и преобразуется в стандартное EDI
- сообщение и будет передан по Intranet на EDI-сервер компании.
Рис. 2
На рис.2 представлена схема формирования XML документа на
клиентской стороне. В ходе начала обмена, клиент принимает от XML сервера шаблон
(формально назовем XML шаблон). Текст простого шаблона на примере XML документа
"инвойс" может иметь следующий вид: <?xml version="1.0">
<!DOCTYPE InvoiceForm >
<?xml-stylesheet type="text/xsl" server-config="Config.xml"
href=" InvoiceForm.xsl" ?>
<Transaction id="768765324">
<ItemQuantity>3</ItemQuantity>
</Transaction>
Элемент <Transaction> включает атрибут id,
указывающий номер транзакции имеющий значение "768765324".
Элемент <ItemQuantity> описывает количество "пунктов"
инвойса, т.е. количество наименований перевозимого товара. Далее, используя язык
описания стилей XSL, генерируется HTML форма, которая заполняется данными об
отправителе и получателе груза, а также о самом грузе. Внешнее представление
сгенерированной формы принципиального значения не имеет и может быть разработано
получателем документа самостоятельно. Также, возможно использование заранее
подготовленной HTML формы с параметром id тага Transaction.
Рис. 3
Упрощенный вид генерируемой HTML формы представлен на рис. 3.
После инициации события OnClick кнопки "Передача" (SUBMIT) происходит
генерация следующего XML документа: <?xml version="1.0">
<!DOCTYPE Invoice>
<Transaction id="768765324">
<InvoiceNum>12345<InvoiceNum> <!-- номер инвойса -->
<DataSend>20000105</DataSend> <!-- YYYYMMDD 5/01/2000 -->
<Consignor>
<ConsignorName>OY Valio</ConsignorName> <!-- Отправитель -->
<Address> <!-- Адрес -->
<City>Helsinki</City>
<Street/>
<Zip>Box 789</Zip>
<Country>FI</Country>
</Address>
</Consignor>
<Consignee> <!-- Получатель -->
<ConsigneeName>АО Северная столица</ConsigneeName>
<Address>
<City>Санкт-Петербург</City>
<Street>Невский 176</Street>
<Zip>194376</Zip>
<Country>RU</Country>
</Address>
</Consignor>
<Goods> <!-- Описание товаров -->
<Item id=1> <!-- Первая позиция -->
<Name>Сыр</Name> <!-- Наименование товара -->
<Qulity>200</Qulity> <!-- кол-во -->
<TypeEQU>AAI</TypeEQU> <!-- тип измерения AAI - по весу -->
<Price>300</ Price> <!-- Цена за ед. -->
<Currently>FIM</Currently> <!-- тип используемой валюты -->
</Item>
<Item id=2> <!-- Вторая позиция -->
<Name>Масло</Name>
<Qulity>150</Qulity>
<TypeEQU>AAU</TypeEQU> <!-- тип измерения AAU - упаковки-->
<Price>500</ Price>
<Currently>FIM</Currently>
</Item>
<Item id=2> <!-- Третья позиция -->
<Name>Варенье</Name>
<Qulity>100</Qulity>
<TypeEQU>AAU</TypeEQU>
<Price>180</ Price>
<Currently>FIM</Currently>
</Item>
</Goods>
</Transaction>
Данный документ принимается XML сервером, который генерирует
следующее EDI - сообщение:
UNH+768765324+INVOIC:D:96A:UN:EAN002' BGM+380+12345+9+NA' DTM+3:20000105:102' NAD+SE+++OY
Valio++Helsinki++Box 789+Fi'
NAD+By+++АО Северная столица ++Saint-Peterburg+Невский 176 +
+RU' |
Заголовок Сообщения Номер транзакции 768765324 Номер инвойса
12345 Дата выдачи 5.01.2000 Поставщик Valio Адр: Helsinki Box 789
FI Получатель "АО Северная столица" Адр: С-Петербург Пр. Невский
176 Россия |
LIN+1' IMD+F+011+:::Сыр' MEA+AAI' QTY+92:200' PRI+INV:300' CUX+2:USD'
|
Первая позиция Наим. Сыр Ед.изм- кг Кол-во 200 кг Цена
300 за кг Валюта - USD |
LIN+2' IMD+F+011+:::Масло' MEA+AAU' QTY+92:150' PRI+INV:500' CUX+2:USD'
|
Вторая позиция Наим. Масло Ед.изм- упак Кол-во 150
упак Цена за упак - 500 Валюта - USD |
LIN+3' IMD+F+011+:::Варенье' MEA+AAU' QTY+92:100' PRI+INV:180' CUX+2:USD'
|
Третья позиция Наим. Варенье Ед.изм- упак Кол-во 100
упак Цена 180 за упак Валюта - USD |
UNS+S' CNT+4:3' UNT+26+12345' |
Контрольная секция Общее кол-во позиций- 3 Кол-во сегментов -
26 и Номер сообщения - 12345 |
Особой задачей для семантической проверки и разбора XML
документа и формирования EDIFACT сообщения является разработка Таблицы
определения данных - DTD. При разработке DTD, учитывая иерархическую структуру
EDIFACT сообщения, разрабатывается объектная модель документа - DOM. На рис 3
представлена иерархическая схема сообщения INVOICE.
В рассматриваемом EDIFACT сообщении INVOICE можно выделить
сегменты и сопоставить их с объектами ELEMENT объектной модели. В левой части
таблицы представлены DOM элементы, а в правой соответствующие им сегменты или
части сегментов. Значок # указывает, что в данном месте должно находится
значение из соответствующего элемента DOM.
Корневой элемент Name= "Transaction" Attr "id =
#" |
Сегмент UNH UNH +#+INVOIC:D:96A:UN:EAN002' |
Элементы:
Name ="InvoiceNum" Value = # |
Сегмент BGM BGM+380+#+9+NA' |
Name ="Consignor " |
Сегмент NAD NAD+SE+++#01++#02' |
Дочерние элементы "Consignor "
Name = "ConsignorName" Value = #01
Name ="Addsress" Value = #02 |
|
Name ="Consignee " Дочерние элементы "Consignee
" Name ="ConsigneeName " Value = #01
Name ="Addsress" Value = #02 |
NAD+BY+++#01++#02' |
Name ="Addsress" Дочерние элементы
"Addsress" Name ="City " Value = #01
Name ="Street" Value = #02
Name ="Zip" Value= #03
Name ="Country" Value= #04 |
Часть Сегмента NAD
#01+#02+#03+#04 |
Name ="Goods" Дочерние элементы
"Goods" Name ="Item " |
Идентификатор группы сегментов: LIN-IMD-QTY-MEA-PTI-CUX |
Name ="Item" Attr "id = #" Дочерние
элементы "Item" Name ="Name" Name
="Qulity" Name ="TypeEQU" Name ="Price
" Name ="TypeCur"
|
Сегмент LIN LIN+#' |
Name ="Name" Value = # |
Сегмент IMD IMD+F+011+:::#' |
Name ="Qulity" Value = # |
Сегмент QTY QTY+92:#' |
Name ="TypeEQU " Value= # |
Сегмент MEA MEA+#' |
Name ="Price" Value= # |
Сегмент PRI PRI+INV:#' |
Name ="TypeCur" Value= # |
Сегмент CUX CUX+2:#' |
|
Интерпретация содержания сегмента осуществляется следующим
образом: значение тага <InvoiceNum> из текста нашего XML документа
( <InvoiceNum>12345<InvoiceNum> ) будет преобразовано в
BGM+380+12345+9+NA', что соответствует записи в левой части таблицы
объкта Element ( Name ="InvoiceNum" Value = # ) и
BGM+380+#+9+NA' в правой. Если какой либо сегмент содержит информацию из
нескольких родственных (Sublin) тагов, то указывается номер вхождения:
Пример: Сегмент NAD содержит информацию из элемента
"ConsigneeName" - вхождение #01 и элемента
"Addsress" - вхождение #02:
Соответственно информация из элемента
"Addsress" извлекается из дочерних элементов ( "City
", "Street" и "Country"), которые имеют свою часть
вхождения в сегмент NAD:
При генерации EDI-сообщения, необходимая информация извлекается
из значений атрибутов, которые описываются как константы элементов DTD. Каждый
элемент, информация из которого имеет вхождение в сегмент сообщения, имеет
атрибуты:
- EDI-Prefics - информация (статическая часть текста сегмента) предшествующая
вхождению переменной;
- EDI-Suffics - статическая часть текста сегмента после вхождения переменной.
Так для тага <InvoiceNum> атрибутом является:
EDI-Prefics - "BGM+380+" EDI-Suffics -
"+9+NA' ".
Для тегов, которые используют информацию при вводе из поля
данных, используются атрибуты Title и Size.
Ниже представлена часть таблицы определения данных, которая
иллюстрирует основы построения DTD для XML/EDI. <!DOCTYPE Invoice [
<!ENTITY InvoiceNum (#PCDATA) >
<!ATTLIST InvoiceNum
EDI-Prefics CDATA #FIXED "BGM+380+"
EDI-Suffics CDATA #FIXED "+9+NA'"
Title CDATA"INVOICE"
Size NUMBER #FIXED "8" >
<!ENTITY Consignor (ConsignorName, Address) >
<!ATTLIST Consignor
EDI-Prefics CDATA #FIXED "NAD+SE+++"
EDI-Suffics CDATA "#FIXED "'"
Title CDATA #FIXED ""
Size NUMBER #FIXED "30" >
<!ENTITY ConsignorName (#PCDATA) >
<!ATTLIST ConsignorName
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA "#FIXED "++"
Title CDATA #FIXED ""Отправитель"
Size NUMBER #FIXED "30" >
<!ENTITY Consignee (ConsigneeName, Address) >
<!ATTLIST Consignee
EDI-Prefics CDATA #FIXED "NAD+BY+++"
EDI-Suffics CDATA "#FIXED "'"
Title CDATA #FIXED ""
Size NUMBER #FIXED "0" >
<!ENTITY ConsigneeName (#PCDATA) >
<!ATTLIST ConsigneeName
EDI-Prefics CDATA #FIXED "Отправитель "
EDI-Suffics CDATA #FIXED "++"
Title CDATA #FIXED "Получатель"
Size NUMBER #FIXED "30" >
<!ENTITY Address (Street?,City,ZIP?,Country) >
<!ATTLIST Address
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "'"
Title CDATA #FIXED "Адрес"
Size NUMBER #FIXED "30" >
<!ENTITY Street (#PCDATA) >
<!ATTLIST Street
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Улица"
Size NUMBER #FIXED "30" >
<!ENTITY City (#PCDATA) >
<!ATTLIST City
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Город"
Size NUMBER #FIXED "30" >
<!ENTITY Zip (#PCDATA) >
<!ATTLIST Zip
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED "+'"
Title CDATA #FIXED "Индекс"
Size NUMBER #FIXED "6" >
<!ENTITY Country (#PCDATA) >
<!ATTLIST Country
EDI-Prefics CDATA #FIXED ""
EDI-Suffics CDATA #FIXED ""
Title CDATA #FIXED "Страна"
Size NUMBER #FIXED "3" >
]>
EDI-сообщение специальным модулем генерируется на серверной
стороне извлекая динамическую информацию из XML документа и статическую из DTD.
Далее сгенерированное сообщение передается в EDI-систему, где и происходит
обработка сообщения.
Двухступенчатое преобразование XML-документа
В предыдущей главе рассказывалось об одном из способов
организации состава клиентской части XML/EDI. Основным недостатком построения
клиентской части по схеме одноступенчатого преобразования является
"мануальностью" системы, т.е. система является не автоматической:
Пользователь из Компании 1 (см. рис 5) должен взять из информационной системы
своей компании информацию и в ручную заполнить форму Браузера, которая формирует
XML документ (На рис. 5 для наглядности изображено два разных компьютера, один
из которых является частью Intranet компании, и другой, который посредством WEB
browser формирует XML документ).
Рис. 5
Компания 2, где расположена серверная часть, осуществляет
автоматическую обработку XML-документа, без непосредственного участия человека.
Было бы целесообразно, организовать обмен электронными документами таким же
образом и на отправляемой стороне, т.е. чтоб человек мог только контролировать
передачу документов, не осуществляя каких-либо ручных операций по заполнению
HTML-форм.
Так на рис. 5, изображена топология внутреннего взаимодействия
в Компании 3, где оператор со своего рабочего места вносит необходимые данные в
информационную систему своей компании, которая автоматически, при определенных
условиях, формирует XML-документ и отправляет его адресату.
Такая организация передачи электронных документов возможна
разными способами: использование встроенных в HTML файл объектов ActiveX или
написание специальных Java программ, которые реализовывали бы серверные обмены.
Другой из возможных вариантов построения системы XML/EDI -
является использование двухступенчатого формирования электронного документа. На
рис. 6 представлена схема двухступенчатого преобразования XML документа в
EDI-сообщение.
Рис.6
На первом этапе, осуществляется преобразование XML-источника,
используя XSL-преобразование стандартным XSL-анализатором, в формат метаданных
XEDI.. По своей сути, формат метаданных XEDI - является своего рода новым
языком, описанного языком разметки.
Второй этап заключается в прямом преобразовании метаданных XEDI
транслятором XML/EDI непосредственно в EDI-сообщение. Аналогичный процесс, но
уже в обратном порядке, происходит при конвертации EDI-сообщения в XML-документ.
Преимущество идеи двухступенчатого преобразования в том, что
метаданные XEDI описывают любые виды EDI-сообщений в соответствии с XEDI
синтаксисом. Одноступенчатое преобразование применяется в основном в системах,
использующих один тип сообщения.
Ниже будут изложены предложения XML-EDI Group, заложенные в
преобразование метаданных.
Сообщение UN/EDIFACT можно разобрать на следующие
самостоятельные единицы, вложенные друг в друга:
- Сообщение
- Группа сегментов
- Сегмент
- Группа Элементов данных
- Элемент данных или Квалификатор
Каждой самостоятельной единице будет соответствовать свой
элемент XML (элемент метаданных XEDI). Можно выделить следующее соответствие
EDI-XML:
Сообщение |
<Message Name=имя сообщения> |
Группа сегментов |
<SegmentGroup> |
Сегмент |
<Segment Name=имя сегмента> |
Группа Элементов данных |
<ElementGroup > |
Элемент данных Квалификатор |
<DataElement id=код данных> |
|
Каждый элемент XML имеет определенный набор параметров, которые
содержат информацию. Возвращаясь к нашему примеру, Все содержание EDI-сообщения
INVOICE будет обрамлено следующими тагами: <Message Name="INVOICE">
..... сегменты и группы сегментов, составляющие сообщение ...
</Message>
Значение атрибута Name для тага <Message>
представляет имя EDI-сообщения. Для упрощения синтаксического анализа и
сохранения наглядности документа вводится таг <SegmentGroup>,
который обрамляет повторяющиеся группы сегментов: <Message Name="INVOICE">
<Segment Name="UNH">
<!-- содержание сегмента UNH -->
</Segment>
<Segment Name="BGM">
<!-- содержание сегмента BGM -->
</Segment>
<!-- ....... информация о сегментах DTM,NAD-->
<SegmentGroup>
<!-- ...... обрамляет группу сегментов (LIN, IMD,MEA,QTY,PRI,CUX) -->
<Segment Name="LIN">
<!-- ...... содержание сегмента LIN -->
</Segment>
<Segment Name="IMD">
<!--...... содержание сегмента IMD -->
</Segment>
<!--..... информация об остальных сегментах группы LIN (MEA,QTY,PRI,CUX) -->
</SegmentGroup>
<!--.... контрольная секция, сегменты UNS,CNT,UNT -->
</Message>
Каждый сегмент содержит группу элементов данных, в соответствии
со справочником сегментов EDSD, который входит в набор стандартов UN/EDIFACT.
Например, в соответствии со справочником EDSD, сегмент NAD (имя и адрес) имеет
следующие описание:
? группы |
Код справочника |
Описание данных |
Усл/обяз |
формат |
010 |
3035 |
КВАЛИФИКАТОР УЧАСТНИКА |
M |
an..3 |
020 |
C082 |
ОСОБЕННОСТИ ИДЕНТИФИКАЦИИ УЧАСТНИКОВ |
C |
|
|
3039 |
Идентификация участников |
M |
an..35 |
|
1131 |
Квалификатор контролирующего органа |
C |
an..3 |
|
3055 |
Код контролирующего органа |
C |
an..3 |
030 |
C058 |
НАЗВАНИЕ И АДРЕС |
С |
|
|
3124 |
Строка имени (названия) и адреса |
M |
an..35 |
|
3124 |
Строка имени (названия) и адреса |
C |
an..35 |
040 |
C080 |
НАЗВАНИЕ УЧАСТНИКА |
С |
|
|
3036 |
Название участника |
M |
an..35 |
|
3036 |
Название участника |
C |
an..35 |
|
3045 |
Код названия участника |
C |
an..3 |
050 |
С059 |
УЛИЦА |
C |
|
|
3042 |
Улица и номер п.я. |
C |
an..35 |
|
3042 |
Улица и номер п.я. |
C |
an..35 |
060 |
3164 |
НАЗВАНИЕ ГОРОДА |
C |
an..35 |
070 |
3229 |
ИДЕНТИФИКАЦИЯ РЕГИОНА |
C |
an..9 |
080 |
3251 |
ИДЕНТИФИКАЦИЯ ПОЧТОВОГО КОДА |
C |
an..9 |
090 |
3207 |
КОД СТРАНЫ |
C |
an..3 |
Возвращаясь к нашему примеру, кодировка в UN/EDIFACT
NAD+SE+++OY Valio++ Helsinki++Box 789+Fi' будет преобразована в: <Segment Name="NAD">
<DataElement id=10 dic=3035> SE </DataElement>
<DataElement id=40> OY Valio </DataElement>
<DataElement id=60> Y=Helsinki </DataElement>
<DataElement id=80> Box 789 </DataElement>
<DataElement id=90 dic=3207> FI </DataElement>
</Segment>
Атрибутом тага <DataElement> id - является номер
группы в справочнике элементов данных, а атрибут dic - номер справочника,
по которому определяется квалификатор.
Элементы данных могут быть простыми и составными, состоящими из
компонентов. Составные элементы данных объединяются тагами <ElementGroup>.
Например, сегмент цена: PRI+INV:180' содержит составной элемент данных,
включающий квалификатор INV (цена по инвойсу) и значение цены - 180: <Segment Name="PRI">
<ElementGroup id=10>
<DataElement id=1 dic=5125> INV </DataElement>
<DataElement id=2 dic=5118> 180 </DataElement>
</ElementGroup>
</Segment>
В данном примере таг <ElementGroup> имеет аттрибут
id, который имеет значение положения составного элемента по справочнику
EDCD. Значения id тага <DataElement> представляет
относительное месторасположение в справочнике сегментов.
Преобразование XML документа в метаданные осуществляется
посредством обработки XQL-запросов анализатором XSL. Ниже представлен текст
запроса для преобразования EDIFACT элемента PRI (таг <Price> ) в
XEDI метаданные: <xsl:template>
xsl:for-each select="//Price">
<Segment Name="PRI">
<ElementGroup id=10>
<DataElement id=1 dic=5125> INV </DataElement>
<DataElement id=2 dic=5118>
<xsl:value-of select="//Price"/>
</DataElement>
</ElementGroup>
</Segment>
</xsl:for-each>
</xsl:template>
Таг <xsl:template> определяет область действия
шаблона XSL фильтра, а таг <xsl:for-each> определяет область
шаблона, на которую распространяется данный запрос. Параметр select определяет
область действия запроса в соответствии с синтаксисом запроса. Таг
<xsl:value-of select=строка запроса /> осуществляет подстановку
результата.
Синтаксис строки запроса схож с обычным способом определения
пути к ресурсу- список узлов дерева, разделенных символом /. Для выделения всех
дочерних элементов - используется символ "*", для выделения элемента,
расположенного просто "ниже" по дереву(на любом уровне вложенности)
символ - "//". Условие на значение в запросе должно заключаться в
символы "[" и "]". Для выбора значения атрибута в условии
указывается символ @.
Примеры простых шаблонов:
" Transaction/" |
возвращает дочерние элементы для элемента Transaction |
"Consignor//" |
список всех элементов, вложенных в Consignor |
"SegmentName[@Id]" |
список элементов SegmentName, в котором определен атрибут Id |
"SegmentName [@Id=2]" |
поиск всех тагов, которые имеют значение атрибута id равное
2 |
При формировании ответа на сообщение обратное преобразование из
метаданных в XML-документ, осуществляется с помощью следующего шаблона: <xsl:template>
xsl:for-each select="//Segment/">
<Price>
<xsl:value-of select=" Segment[@Name="PRI"]/DataElement[@Id="2"]"/>
</Price>
</xsl:for-each>
</xsl:template>
Данный запрос интерпретируется как: выбрать все значения из
тагов <DataElement>;, имеющие значение параметра Id="2",
и которые имеют вхождение в таги <Segment> со значением параметра
Name="PRI".
Выполнение более сложных запросов, например, при формировании
метаданных для сегмента NAD осуществляется, учитывая уровни вложенности: <xsl:template>
xsl:for-each select="//Consignor">
<Segment Name="NAD">
<DataElement id=10 dic=3035> SE </DataElement>
<DataElement id=40>
<xsl:value-of select="//Consignor/ConsignorName"/>
</DataElement>
<DataElement id=50>
<xsl:value-of select="//Consignor/Address/Street"/>
</DataElement>
<DataElement id=60>
<xsl:value-of select="//Consignor/Address/City"/>
</DataElement>
<DataElement id=80>
<xsl:value-of select="//Consignor/Address/Zip"/>
</DataElement>
<DataElement id=90 dic=3207>
<xsl:value-of select="//Consignor/Address/Country"/>
</DataElement>
</Segment>
</xsl:for-each>
</xsl:template>
В заключение хочется отметить, что предлагаемый способ
формирования XEDI метаданных находится на стадии утверждения. В настоящее время
в XML-EDI Group находится на рассмотрении предложения по комбинированному
формированию метаданных, при котором используется конверсия не только стандарта
UN/EDIFACT, но и не менее популярного в США и Германии стандарта формирования
электронных документов ANSI X12.
Литература по XML
|