ГОСТ Р ИСО/МЭК 29363—2013
• UDDI Механизм вложения деклараций для конкретных веб-служб (Claim Attachment
Mechanism for Web Services Instances -
ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ.
URI декларации о соответствии для этого профиля
http://wsi.org/profiles/attachments/1.0.
3 Обмен сообщениями
Данный раздел профиля включает следующие ссылки на спецификации и определяет
возможные в них расширения:
•Простой протокол доступа к объектам версии 1.0 (Simple Object Access Protocol (SOAP) 1.1).
•Расширяемый язык разметки (XML) 1.0 (Вторая Редакция) (Extensible Markup Language
(XML) 1.0 (Second Edition)).
•Пространства имен в XML 1.0 (Namespaces in XML 1.0).
•RFC2616: протокол HTTP версии 1.1 (Hypertext Transfer Protocol - HTTP/1.1).
3.1 Сериализация сообщения (Message Serialization)
Для передачи сообщений SOAP 1.1 определяет структуру XML-конверт. Профиль налагает
требования на использование этой структуры, и определяет следующие ограничения на ее
использование.
3.1.1 Сериализация конверта XML (XML Envelope Serialization)
R9700 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт как особое информационное
наполнение тела объекта HTTP.
R9701 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт как XML 1.0.
R9702 В СООБЩЕНИИ ДОЛЖНО присутствовать поле «Content-Type» HTTP-заголовка.
R9703 Поле «Content-Type»HTTP-заголовка СООБЩЕНИЯ ДОЛЖНО иметь значение, тип
медиа (media type) которого - «text/xml».
3.1.2 Объявления пространства имен XML
Хотя опубликованное исправление NE05 (см.
http://www.w3.org/XMI_/xml-names-19990114-errata
)
допускает присутствие такого объявления пространства имен, некоторые более старые системы
обработки считают такие объявления ошибкой.
R9704ВКОНВЕРТНЕСЛЕДУЕТпомещатьобъявлениепространстваимен
xmlns:xml=
nhttp://v/ww.w3.org/XML/1998/namespace*.C
3.1.3 Маркеры последовательности байтов юникода (Unicode BOMs)
XML 1.0 допускает включение маркеров последовательности байтов (ВОМ) при кодировке UTF-
8. поэтому получатели конвертов должны быть готовы принять их. Маркер последовательности
байтов обязателен для XML при кодировании как UTF-16.
R4001ПОЛУЧАТЕЛЬ ДОЛЖЕНпринимать конверты, в которые включены маркеры
последовательности байтов юникода (ВОМ).С
3.1.4 Декларация XML (XML Declaration)
Наличие или отсутствие декларации XML не влияет на функциональную совместимость. В
отдельных реализациях объявления XML могут всегда предшествовать их XML - сериализации.
R1010 ПОЛУЧАТЕЛЬ ДОЛЖЕН принимать сообщения с конвертами, которые содержат
декларацию XML. С
3.1.5 Кодирование символов
Для обеспечения функциональной совместимости профиль требует, чтобы процессоры XML
поддерживали кодирование символов UTF-8 и UTF-16.
Как следствие этого, в сочетании требованием SOAP 1.1 использования в конвертах типа
медиа (media type) «text/xml», у которого кодировка символов по умолчанию «us-ascii»), параметр
«charset» должен всегда присутствовать в «content-type» конверта. Дальнейшее следствие этого - тот
факт, что псевдоатрибут кодирования из объявления XML всегда игнорируется в пределах
сообщения, в соответствии с требованиями как XML 1.0. так и RFC3023. «XML Типы медиа»(ХМЬ
Media Types).
Для определения правильной кодировки символов сообщения должен использоваться параметр
«charset» поля Content-Type HTTP-заголовка.При отсутствии параметра «charset» должно
использоваться значение набора символов по умолчанию, которым является «us-ascii».
R1012 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт, используя кодировку символов либо
UTF-8, либо UTF-16.
R1018 Значение поля «Content-Type»HTTP-заголовка СООБЩЕНИЯ ДОЛЖНО указать на
правильную кодировку символов, используя параметр «charset» С
4