Ссылки элемента (Element References)
Рисунок .9. Ссылки элемента (Element References)
Атрибуты ссылки элемента определены как "NMTOKEN", а не "IDREF" (смотри [XML]). Это сделано потому, что IDREF требует, чтобы элемент XML, на который ссылаются, принадлежал тому же XML-документу. В IOTP это не всегда так.
3.6. Расширение IOTP
Базовая версия IOTP определяет минимальный протокол, с которым система, поддерживающая IOTP, должна быть способна работать. По мере разработки новых версий IOTP будут определяться дополнительные типы транзакций IOTP. Кроме того, базовая и будущие версии IOTP будут поддерживать два механизма расширения возможностей IOTP пользователем:
o дополнительные XML-элементы
o новые значения существующих IOTP-кодов.
3.6.1. Дополнительные XML-элементы
Имена XML элементов и атрибутов используемых в IOTP составляют пространство имен [XML], как это определено атрибутом xmlns элемента IotpMessage. Это позволяет Th IOTP поддерживать включение дополнительных XML-элементов в IOTP-сообщения посредством использования пространства имен XML. Используя XML Namespaces, дополнительные XML-элементы могут быть включены на любом уровне в сообщение IOTP, включая:
o новые торговые блоки
o new торговые компоненты
o новые XML-элементы торгового компонета.
При этом следуют определенным правилам:
| о | Любой новый XML-элемент должен быть декларирован согласно правилам [XML Namespaces] |
| o | Новые XML-элементы, которые являются торговыми блоками или компонентами должны содержать ID-атрибуты с именем атрибута ID. |
Для того чтобы быть уверенным, что дополнительные элементы XML могут быть обработаны корректно, IOTP резервирует использование специального атрибута, IOTP:Critical, который принимает значение True или False и может появляться в дополнительных элементах, добавляемых к IOTP-сообщению. Целью этого атрибута является допущение IOTP проинформировать приложение, можно ли безопасно продолжить транзакцию. В частности:
- Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "True" и IOTP уведомлен приложением, что оно не знает как обрабатывать элемент и его дочерние элементы, тогда транзакция IOTP выдает техническую ошибку (смотри раздел 4.1).
- Если дополнительный XML-элемент имеет атрибут "IOTP:Critical" со значением "False", тогда транзакция IOTP может продолжать работу, если IOTP уведомлен о том, что приложение не знает как обработать этот элемент.
В этом случае:
| - любые дополнительные XML-элементы, содержащиеся в XML-элементе и определенные в пространтстве имен IOTP, должны включать этот элемен всякий раз, когда IOTP XML- элемен используется или копируется IOTP. | |
| - содержимое дополнительного элемента следует игнорировать, за исключением случая, когда оно должно учитываться при генерации дайджеста в ходе формировании электронной подписи. |
- Если дополнительный XML-элемент не имеет атрибута "IOTP:Critical", тогда он должен обрабатываться так, как если бы имел атрибут "IOTP:Critical" со значением "True"
- Если XML-элемент содержит атрибут "IOTP:Critical", тогда значение атрибута следует использовать во всех дочерних элементах этого элемента.
| IOTP:Critical | (True | False ) 'True' |
Если IOTP должен быть расширен с помощью Opaque Embedded Data, тогда к инкапсулированным данным должен быть применен элемент Packaged Content (смотри раздел 3.7).
3.7. Элемент PackagedContent
Элемент PackagedContent поддерживает концепцию потока вложенных данных, преобразованную, чтобы защитититься от неверной интепретации транспортной системой и гарантировать совместимость с XML. Примеры использования этого элемента в IOTP включают:
o для инкапсуляции сообщений платежной системы, таких как сообщения SET,
o для инкапсуляции описания заказа, чека (payment note) или накладной (delivery note).
В общем, он используется для инкапсуляции одного или более потоков данных. Этот поток данных имеет три стандартизованных атрибута, которые служат для идентификации, декодирования и интерпретации содержимого. Его определение представлено ниже.
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >
Атрибуты:
| Name | Опционно. Позволяет разделить случаи множественного применения элементов PackagedContent в одной и той же точке IOTP. Например: |
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
Атрибут имени может быть опущен, например, если имеется только один элемент PackagedContent.
| Content | Идентифицирует, какой тип данных находится в содержимом элемента PackagedContent. Корректными значениями атрибута Content являются: |
| о | PCDATA. Содержимое элемента PackagedContent может рассматриваться как PCDATA и более не обрабатываться. |
| о | MIME. Содержимое элемента PackagedContent является MIME-объектом. Обработка должна включать поиск MIME-заголовков внутри элемента PackagedContent. |
| о | MIME:mimetype. Содержимое элемента PackagedContent является MIME-объектом с заголовком "Content-Type: mimetype". Хотя допускается иметь MIME:mimetype с атрибутом Transform равным NONE, более желательно иметь атрибут Transform равным BASE64. Заметим, что, если используется Transform = NONE, тогда все содержимое должно соответствовать PCDATA. Некоторые символы будет нужно закодировать как объекты XML, или как символьные объекты. |
| о | XML. Содержимое элемента PackagedContent может рассматриваться как XML-документ. Следует использвать секции CDATA, или Transform = BASE64, чтобы гарантировать, что содержимое элемента PackagedContent соответствует PCDATA. |
| Transform | Идентифицирует преобразование, которое было произведено нс даннвми, прежде чем они были помещены элемент. Допустимыми значениями являются: |
- NONE. Содержимое элемента PackagedContent типа PCDATA является корректным представлением данных. Заметим, что разворачивание объекта должно быть произведено (т.e. замена & и 	) до анализа данных. Секции CDATA могут встречаться в элементе PackagedContent, где атрибут Transform равен NONE.
- BASE64. Содержимое элемента PackagedContent типа PCDATA представляет собой BASE64 кодировкуреального содержимого.
| PCDATA | Это действительные данные, которые вложены в элемент. Формат данных и правила их кодирования записаны в атрибутах Content и Transform. |
PackagedContent может содержать HTML. В этом случае должны выполняться следующие условия:
- Ссылки на любой документы, изображения или другие вещи, такие как звук или WEB-страницы, могут влиять на понимание данных получателем, которые должны соотноситься с другими элементами Packaged, содержащимися в том же родительском элементе, например, описание заказа.
- Если, для того чтобы удовлетворить рассмотренным выше требованиям, в исходный элемент включен более чем один элемент PackagedContent, тогда атрибут Name верхнего уровня, который определяет ссылки на все другие элементы Packaged, должен иметь значение Main.
- Относительные ссылки на другие документы, изображения и т.д. одного элемента PackagedContent на другой реализуются путем установления значения относительной ссылки на атрибут Name другого элемента PackagedContent на том же уровне и в пределах того же родительского элемента.
- Никакие внешние ссылки, которые требуют немедленного разрешения, не должны быть использованы. Так как это может осложнить или сделать невозможным отображение HTML.
- [MIME] используется, чтобы инкапсулировать данные в пределах каждого элемента Packaged. Это означает, что информация в заголовке MIME использована для идентификации типа данных, которые инкапсулированы.
В качестве руководства разработчику следует иметь в виду, что значения атрибутов Name, относящиеся к элементам PackagedContent, должны допускать извлечение каждого PackagedContent в каталог и отображение HTML непосредственно.
3.7.2. Пакетирование XML
Рекомендуется поддержка XML. Когда необходимо отобразить XML, например, чтобы представить содержимое описания заказа Покупателю, разработчики должны следовать новейшим рекомендациям консорциума World Wide Web.
3.8. Идентификация языков
IOTP использует идентификацию языка [XML] для того, чтобы специфицировать, какие языки применены в тексте и атрибутах IOTP-сообщения.
Для того чтобы определить, какие элементы XML содержат атрибуты xml:lang, нужно придерживаться следующих принципов:
- обязательный атрибут xml:lang содержится в каждом торговом компоненте, где присутствуют атрибуты или содержимое, которое требует отображения или печати на определенном языке;
- опционный атрибут xml:lang вводится в дочерние элементы торговых компонентов. В этом случае значение xml:lang, если оно имеется, переписывает значение для торгового компонента.
Отправитель сообщения, обычно Покупатель, может указать свои предпочтения для языка и символьного набора путем спецификации соответствующего списка в Id-компоненте сообщения (смотри раздел 3.3.2). Заметим, что получатель такого сообщения не обязан строго следовать этим предпочтениям, так как он может не иметь необходимых средств для этого. Это также означает, что возможность работать с этими списками не является требованием данной спецификации. Однако возможность реагировать, используя один из объявленных языков или символьных наборов является желательной.
3.9. Безопасные и небезопасные позиции в сети
IOTP содержит несколько "сетевых позиций", которые определяют место, куда молгут быть посланы сообщения IOTP-сообщения. Сетевые позиции (Net Locations) бывают двух типов:
- "Безопасные" сетевые позиции, где конфиденциальность данных гарантируется с помощью, например, некоторых методов шифрования, таких как [SSL/TLS].
- "Небезопасные" сетевые позиции, где конфиденциальность данных не гарантируется.
Если присутствует одна из двух сетевых позиций, только она и может использоваться.
Там где представлены оба типа сетевых позиций, допускается использование обоих, в зависимости от предпочтения отправителя сообщения.
3.10. Аннулированные транзакции
Любая торговая роль, вовлеченная в транзакцию IOTP может аннулировать эту транзакцию в любой момент.
3.10.1. Аннулирование транзакций
Транзакции IOTP аннулируются путем посылки сообщения IOTP, содержащего блок Cancel с соответствующим компонентом Status, другой торговой роли, вовлеченной в торговый обмен.
Блок Cancel может быть послан асинхронно по отношению к любому другому сообщению IOTP. В частности он может быть послан до посылки или после получения сообщения от другой торговой роли.
Если транзакция IOTP аннулирована во время торгового обмена (т.e. интервал между отправкой блока "запрос" и получением соответствующего ему блока "отклик"), тогда блок Cancel посылается тому же адресату, что и следующее сообщение IOTP в торговом обмене.
Если покупатель аннулирует транзакцию после завершения торгового обмена (т.e. блок "отклик" торгового обмена уже получен), но до завершения тразакции IOTP, покупатель посылает блок Cancel с соттветствующим компонентом Status сетевой позиции, идентифицированной SenderNetLocn или SecureSenderNetLocn, содержащимся в компоненте опции протокола (смотри раздел 7.1), который размещен в блоке TPO (смотри раздел 8.1). Это обычно торговая роль Продавца.
Покупатель не должен посылать блок Cancel после того как завершилась транзакция IOTP. Аннулирование всей транзакции будет рассматриваться как техническая ошибка.
После аннулирования транзакции IOTP, Покупатель должен обратиться в сетевую позицию, специфицированную атрибутом CancelNetLocn, содержащимся в элементе торговой роли для организации, которой был послан блок Cancel. Торговые роли, отличные от Покупателя, могут аннулировать транзакцию в следующих случаях:
| о | после получения блока запроса; |
| o | до посылки блока отклика. |
3.10.2. Обработка аннулированных транзакций
Если блок Cancel получен Покупателем в момент, когда аннулирование разрешено, тогда покупатель должен прервать транзакцию.
Если блок Cancel получен торговой ролью, отличной от Покупателя, тогда торговой роли следует ожидать, что Покупатель обратится к сетевойму узлу, специфицированному атрибутом CancelNetLocn, содержащимся в элементе Trading Role.
