Товары в корзине: 0 шт Оформить заказ
Стр. 1 

13 страниц

Международный стандарт определяет профиль WS-I (Организации функциональной совместимости веб-служб – Web Services Interoperability Organization) простой привязки SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) версии 1.0 (далее «профиль»), состоящий из набора открытых спецификаций веб-служб вместе с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости.

 Скачать PDF

Идентичен ISO/IEC 29363:2008

Оглавление

1 Область применения и введение

2 Соответствие профилю

3 Обмен сообщениями

4 Описание

Приложение А Ссылки на спецификации

Приложение В Возможные расширения

Приложение С Нормативные ссылки

Приложение D Благодарности

 

13 страниц

Дата введения01.01.2015
Добавлен в базу21.05.2015
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

08.11.2013УтвержденФедеральное агентство по техническому регулированию и метрологии1541-ст
РазработанООО ИАВЦ
ИзданСтандартинформ2014 г.

Information technology - Web services interoperability - WS-I Simple SOAP Binding Profile Version 1.0

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

(Щ)

ГПГТ Р

НАЦИОНАЛЬНЫЙ 1 1 г

стандарт ИСО/МЭК

РОССИЙСКОМ оооео ФЕДЕРАЦИИ ZyODO-

2013

Информационная технология Функциональная совместимость веб-служб. Профиль WS-I простой привязки SOAP. Версия 1.0

Information technology -

ISO/IEC 29363:2008 - Web Services Interoperability — WS-I Simple SOAP Binding Profile Version 1.0 (IDT)

Издание официальное

Москва

Стандартинформ

2014

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационный аналитический вычислительный центр» (ООО «ИАВЦ») на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ приказом Федерального агентства по техническому регулированию и метрологии от 08 ноября 2013 г. № 1541-ст

4    Настоящий стандарт идентичен международному стандарту ИСО/МЭК 29363:2008 «Информационные технологии. Функциональная совместимость веб-служб. Профиль WS-I простой привязки SOAP Версия 1.0» (ISO/IEC 29362:2008 «Infonnation technology - Web Services Interoperability — WS-I Simple SOAP Binding Profile Version Version 1.0»)

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5 (пункт 3.5).

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты». а официальный текст изменений и поправок - в ежемесячном информационном указателе к Национальные стандарты» В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

© Стандартинформ. 2014

Настоящий стандарт не может быть воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Федерального агентства по техническому регулированию и метрологии

ГОСТ Р ИСО/МЭК 29363—2013

Введение

Настоящий международный стандарт определяет профиль WS-I (Организации функциональной совместимости веб-служб - Web Services Interoperability Organization) простой привязки SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) версии 1.0 (далее «профиль»), состоящий из набора открытых спецификаций веб-лужб вместе с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости.

ИСО/МЭК 29363 был подготовлен Организацией функциональной совместимости веб-служб -Web Services Interoperability Organization (WS-I) и был принят Объединенным Техническим Комитетом СТК 1 ИСО/МЭК Информационные технологии в соответствии с процедурой для опубликованных технических спецификаций параллельно с его одобрением национальными органами ИСО и МЭК.

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология Функциональная совместимость веб-служб Профиль WS-I простой привязки SOAP. Версия 1.0

Information technology - Web Services Interoperability — WS-I Simple SOAP Binding Profile Version 10

Дата введения — 2015—01—01

1 Область применения и введение

1.1    Область применения

Настоящий международный стандарт определяет профиль WS-I (Организации функциональной совместимости веб-служб - Web Services Interoperability Organization) простой привязки SOAP (Simple Object Access Protocol — простой протокол доступа к объектам) версии 1.0 (далее «профиль»), состоящий из набора открытых спецификаций веб-служб вместе с разъяснениями и усилениями тех спецификаций, которые предназначены для обеспечения функциональной совместимости.

В разделе 1 приводится описание профиля и объясняется его отношения с другими профилями.

Раздел 2 «Соответствие профиля» объясняет, что значит быть совместимым с профилем.

Каждый последующий раздел рассматривает компонент профиля и состоит из двух частей: общего описания, в котором детализируются спецификации компонентов и вопросы их расширяемости, и последующих подразделов, в которых рассматриваются отдельные части спецификаций компонентов. Необходимо отметить, что связи между номерами разделов в данном международном стандарте и номерами разделов в спецификациях, на которые имеются ссылки, нет.

1.2    Отношения с другими профилями

Данный профиль разработан исходя из тех требований основного профиля 1.0, которые связаны с преобразованием конверта в последовательную форму и его представления в сообщении и включая все исправления опечаток до настоящего времени. Эти требования были вынесены из основного профиля 1.1. с тем чтобы позволить другим профилям быть скомпонованными с ним.

Объединенное требование соответствия и к основному профилю 1.1 и к профилю простой привязки SOAP 1.0 примерно эквивалентно требованию соответствия к основному профилю 1.0.

1.3    Условные обозначения

Ключевые слова «ДОЛЖЕН» (MUST), «НЕ ДОЛЖЕН» (MUST NOT). «ТРЕБУЕМЫЙ» (REQUIRED), «БУДЕТ» (SHALL), «НЕ БУДЕТ» (SHALL NOT). «СЛЕДУЕТ» (SHOULD). «НЕ СЛЕДУЕТ» (SHOULD NOT), _ «РЕКОМЕНДУЕМЫЙ» (RECOMMENDED). «МОЖЕТ» (MAY) и «ДОПОЛНИТЕЛЬНЫЙ» (OPTIONAL) в данном документе должны интерпретироваться в соответствии с RFC2119.

Нормативные положения для требований профиля (т е. те, которые влияют на соответствие, как описано в «Требованиях соответствия»), представлены следующим способом:

Rnnnn Текст положения.

где nnnn - уникальное среди требований профиля число, в результате чего образуется уникальный идентификатор требования.

Таким образом, идентификаторы требований могут рассматриваться как квалифицированное пространство имен, совместимое с QNames из Пространства имен в XML. Если идентификатор требования не содержит никакого явного префикса пространства имен (например. «R9999» в отличие от «bp10:R9999»), то он должен рассматриваться как принадлежащий пространству имен, определяемому соответствующим универсальным идентификатором ресурса (URI) раздела документа, в котором он присутствует. Если эти условия соблюдены, то префикс следует интерпретировать согласно фактическим отображениям пространства имен, как показано далее.

Некоторые требования используются для пояснения соответствующих спецификаций, но не накладывают дополнительных ограничений на реализацию. Для удобства такие пояснения обозначаются следующим способом: С

Отдельные требования являются результатом постоянно продолжающейся работы по стандартизации спецификаций, на которые они ссылаются Для удобства такие положения, которые могут претерпеть изменения, обозначаются как: хххх. где хххх является идентификатором

Издание официальное

спецификации (например, «WSDL20» для версии 2.0 WSDL). Необходимо отметить, что, поскольку эта работа не была завершена на момент публикации данного документа, спецификация, к которой относится требование, может измениться, и данная информация приводится только для удобства разработчиков.

В данной спецификации используется несколько префиксов пространств имен, которым соответствуют универсальные идентификаторы ресурсов URI, приведенных. Необходимо отметить, что выбор любого префикса пространства имен произволен и не является семантически существенным.

•    wsdl - «http://schemas.xmlsoap.org/Wsdl/»

•    soapbind - «http://schemas.xmlsoap.org/wsdl/soap/»

•    uddi - «urn:uddi-org:api_v2»

1.4 Идентификация профиля и управление версиями

Данный документ идентифицирован наименованием (в данном случае - «Профиль простой привязки SOAP») и номером версии (здесь - 1.0). В совокупности они идентифицируют конкретный экземпляр профиля.

Номера версий составлены из основной и дополнительной частей в форме «основнойдополнительный». Они могут использоваться, чтобы определить приоритет экземпляра профиля: больший номер версии (с учетом и основного, и дополнительного компонентов) указывает, что данный экземпляр новее, и поэтому заменяет более ранние экземпляры.

Для экземпляров профилей с одинаковыми именами (например. «Пример Профиля 1.1» и «Пример Профиля 5.0») проблемы функциональной совместимости рассматриваются в одной и той же общей области действия, хотя при некоторых разработках может потребоваться, чтобы точная область действия профиля была различна для различных экземпляров

Данная информация может также быть использована, чтобы определить являются ли два экземпляра профиля обратно совместимыми, т е. можно ли считать, что соответствие более раннему экземпляру профиля подразумевает соответствие более позднему. Экземпляры профиля с одним тем же именем и номером основной версии (например. «Пример Профиля 1.0» и «Пример Профиля 1.1») МОГУТ считаться совместимым. Совместимость в другом направлении не подразумевается, т е. нельзя предполагать, что соответствие более позднему экземпляру профиля подразумевает соответствие более раннему.

2 Соответствие профилю

Соответствие профилю определено точным выполнением набора требований, определенных в рамках области применения профиля для определенной цели. Настоящий раздел объясняет эти термины и описывает, как определяется и используется соответствие.

2.1 Требования соответствия

Требования устанавливают критерии соответствия профилю. Они обычно ссылаются на существующую спецификацию и добавляют усовершенствования, усиления, интерпретации и разъяснения к ней. чтобы улучшить функциональную совместимость. Все требования в профиле считаются нормативными. Требования в спецификациях, на которые профиль ссылается в области действия (см. «Область соответствия»), также должны рассматриваться как нормативные. В случае, если требования в профиле и в спецификациях, на которые они ссылаются, противоречат друг другу, требования профиля имеют приоритет с целью обеспечения соответствия профиля.

Уровни обязательности требования, обозначенные в соответствии с RFC2119 (например. ДОЛЖЕН, МОЖЕТ. СЛЕДУЕТ и т.п.), указывают на природу требования и его воздействия на соответствие. Для удобства каждое требование имеет индивидуальный идентификатор (например. R9999).

Пример - R9999 Виджетам (WIDGETs) СЛЕДУЕТ (SHOLUD) быть круглой формы.

Это требование, идентифицированное как R9999, применяется к целевому ВИДЖЕТУ (WIDGET) (см. далее) и предъявляет условное требование к совокупности виджетов, т е. хотя это требование в большинстве случаев должно быть удовлетворено, чтобы реализация соответствовала профилю, имеются отдельные ситуации, когда могут быть уважительные причины нарушения требования. Такие причины объясняются непосредственно в требовании или в сопровождающем его тексте.

Каждое положение требований содержит одно и только одно ключевое слово уровня обязательности требования (например. «ДОЛЖЕН» (MUST)) и одно ключевое слово цели соответствия (например. «СООБЩЕНИЕ» (MESSAGE)). Ключевое слово цели соответствия показано жирным шрифтом (например. «СООБЩЕНИЕ» (MESSAGE)). Другие цели соответствия, показанные не жирным шрифтом, используются строго для их определения, а НЕ для цели соответствия. Для объяснения требования или группы требований может быть включен дополнительный текст

2

ГОСТ Р ИСО/МЭК 29363—2013

(например, обоснование и примеры); однако, текст, не входящий непосредственно в положения требований, не должен рассматриваться при определении соответствия.

Определения терминов профиля считаются надежными для целей определения соответствия.

Ни одно из требований профиля, независимо от уровня его обязательности, не должно быть истолковано как ограничивающее возможность реализации соответствующих контрмер безопасности в ответ на реальные или предполагаемые угрозы (например, на атаку отказа в обслуживании).

2.2    Цели соответствия

Цели соответствия определяют, к каким артефактам применяются требования. Примерами целей являются: сообщение SOAP, описание WSDL (Web Services Description Language— язык описания веб-служб и доступа к ним), данные реестра UDDI (Universal Description Discovery & Integration — инструмент для расположения описаний веб-служб) или стороны, например, процессор SOAP, конечный пользователь.

Это позволяет определить соответствие в различных контекстах для гарантии однозначной интерпретации применимости требований и обеспечения проверки артефактов (например, сообщений SOAP и описаний WSDL) и функциональных возможностей различных сторон на соответствие веб-службе (например, конкретным клиентам и службам).

Для обеспечения однозначности и упрощения тестирования целями соответствия в требованиях являются, где это возможно, физические артефакты.

В профиле используются следующие цели соответствия:

•    КОНВЕРТ (ENVELOPE) - преобразование в последовательную форму элемента soap:Envek>pe и его содержимого (см. ИСО/МЭК 29361).

•    СООБЩЕНИЕ (MESSAGE) - элементы протокола, посредством которых осуществляется передача КОНВЕРТА (например, сообщение SOAP/HTTP) (см. ИСО/МЭК 29361).

•    ОПИСАНИЕ (DESCRIPTION) - описания типов, сообщений, интерфейсов и их конкретных протоколов, привязки форматов данных, и сетевых точек доступа, связанных с веб-службами (например, описания WSDL) (см. ИСО/МЭК 29361).

•    РЕАЛИЗАЦИЯ (INSTANCE) - программное обеспечение, которое осуществляет выполнение связывания wsdlport или uddi.bindingTemplate (см. ИСО/МЭК 29361).

•    ПОЛУЧАТЕЛЬ (RECEIVER) - программное обеспечение, которое использует сообщение в соответствии со связанными с ним протоколом или протоколами (например, процессоры SOAP) (см. ИСО/МЭК 29361).

2.3    Область соответствия

Область применения профиля ограничивается технологиями, для которых он предназначен. Другими словами, профиль всего лишь пытается улучшить функциональную совместимость в пределах своей собственной области применения. Обычно область применения профиля ограничена спецификациями, на которые он ссылается.

Область применения профиля уточняется далее возможными расширениями. Технические спецификации зачастую обеспечивают механизмы расширения и неопределенные или открытые параметры конфигурации. В том случае, если в профиле определено возможное расширение, то такой механизм или параметр не входит в область применения профиля, и его использование или неиспользование выходит за рамки требований соответствия.

Обратите внимание, что профиль все же может выдвинуть требования по использованию расширений. Кроме того, конкретные случаи использования расширения могут быть еще более ограничены другими профилями для улучшения функциональной совместимости при использовании сочетания профилей.

Поскольку использование возможных расширений может нарушить функциональную совместимость, их использование должно быть согласовано или задокументировано потребителями веб-служб в некоторой форме, например, в виде дополнительного соглашения.

Область применения профиля определена техническими условиями, перечисленными в Приложении А. и уточняется возможными расширениями, указанными в Приложении В.

2.4    Декларация о соответствии

Декларации о соответствии профилю могут быть сделаны с использованием механизмов, описанных в спецификации «Механизмы вложения деклараций о соответствии», в случае, если были удовлетворены применимые требования профиля, связанные со следующими целями:

•    WSDL 1.1 Механизм вложения деклараций для конкретных реализаций веб-служб (Claim Attachment Mechanism for Web Services Instances) -

ПОЛУЧАТЕЛЬ ЭКЗЕМПЛЯРА ОПИСАНИЯ СООБЩЕНИЯ.

•    WSDL 1.1 Механизм вложения деклараций для конструкций описания (Claim Attachment Mechanism for Description Constructs) -

ОПИСАНИЕ.

3

•    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/XML/xml-names-19990114-errata) допускает присутствие такого объявления пространства имен, некоторые более старые системы обработки считают такие объявления ошибкой.

R9704 В КОНВЕРТ НЕ СЛЕДУЕТ помещать объявление пространства имен xmlns:xml="http://www.w3.org/XML/1998/namespace".C

3.1.3    Маркеры последовательности байтов юникода (Unicode BOMs)

XML 1.0 допускает включение маркеров последовательности байтов (ВОМ) при кодировке UTF-8. поэтому получатели конвертов должны быть готовы принять их. Маркер последовательности байтов обязателен для XML при кодировании как UTF-16.

R4001 ПОЛУЧАТЕЛЬ ДОЛЖЕН принимать конверты, в которые включены маркеры последовательности байтов юникода (BOM).С

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 Типы r.teflna»(XML Media Types).

Для определения правильной кодировки символов сообщения должен использоваться параметр «charset» поля Content-Type HTTP-заголовка. При отсутствии параметра «charset» должно использоваться значение набора символов по умолчанию, которым является «us-ascii».

R1012 СООБЩЕНИЕ ДОЛЖНО сериализировать конверт, используя кодировку символов либо UTF-8, либо UTF-16.

R1018 Значение поля «Content-ТуреяНТТР-заголовка СООБЩЕНИЯ ДОЛЖНО указать на правильную кодировку символов, используя параметр «charset» С

4

ГОСТ Р ИСО/МЭК 29363—2013

R1019 ПОЛУЧАТЕЛЬ ДОЛЖЕН проигнорировать псевдоатрибут кодирования декларации XML в конверте сообщения

4 Описание

Данный раздел профиля содержит ссылку на следующую спецификацию и определяет возможные расширения в ее пределах:

• WSDL 1.1, Section 3

WSDL 1.1 определяет расширение привязки SOAP для описания сообщений, сериапизированных как конверты SOAP. Профипь определяет требования по испопьзованию этой структуры и накладывает ограничения на ее использование, изложенные далее

4.1    Привязки (Bindings)

4.1.1    Расширения привязки SOAP (SOAP Binding Extensions)

Профиль ограничивает выбор привязки WSDL, етко определенной и обычно используемой WSDL привязкой SOAP. В WSDL 1.1 определено, что расширения привязки для HTTP GET/POST и MIME, а также для любых других технологий вложений, профилем не допускаются.

R9802 Элемент wsdl:binding в ОПИСАНИИ ДОЛЖЕН использовать только привязку WSDL SOAP, как определено в разделе 3 WSDL 1.1.

R9800 В ОПИСАНИИ расширения привязки WSDL НЕ ДОЛЖНЫ использоваться элементы и атрибуты, которые вызывают несовместимость с профилем сообщений в процессе их передачи.С

R9801 Расширения WSDL привязок MIME и HTTP GET/POST. а также DIME (Direct Internet Message Encapsulation - прямая инкапсуляция интернет-сообщений) НЕ ДОЛЖНЫ присутствовать в ОПИСАНИИ привязки SOAP.C

Необходимо отметить, что это предьявляет требование к конструкции совместимых элементов привязки wsdi.binding. Это требование не является требованием к описанию в целом; в частности оно не исключает присутствие несовместимых элементов привязки wsdl binding в документах WSDL.

Возможны случаи, когда отправитель может иметь возможность отправлять сообщения, используя SOAP с вложениями, однако не способен получать и обрабатывать такие сообщения.

R2901 В ОПИСАНИИ в каждом из элементов wsdiinput или wsdloutput соответствующего wsdi.binding ДОЛЖНА использоваться или привязка WSDL MIME, как описано в разделе 5 WSDL 1.1. или привязка WSDL SOAP, как описано в разделе 3 WSDL 1.

4.1.2    Несвязанное содержимое элемента portType

WSDL 1.1 не определяет явно, допустимо ли для wsdi.binding оставить неопределенной привязку для частей контента, определенных wsdl portType.

R2209 Привязка wsdi.binding в ОПИСАНИИ ДОЛЖНА связывать каждую часть wsdlpart сообщения wsdimessage. на которые ссылается в wsdiportType,с одним из soapbindbody. soapbindheader, soapbind fault, soapbind headerfault или mimecontent.

portType определяет абстрактный интерфейс (contract) с именованным набором операций и соответствующих абстрактных сообщений. Хотя это и не запрещено, ожидается, что каждая часть абстрактного входящего, исходящего сообщения или сообщения об ошибке, слецифицированого в PortType, связана с soapbind body или soapbind header (и прочими) ипи с mime content соответствующим образом с использованием привязки MIME, как это определено в разделе 5 WSDL 1.1. Несвязанные части wsdlparts должны игнорироваться потребителем.

5

ГОСТ Р ИСО/МЭК 29363—2013

Приложение А

Ссылки на спецификации

В профиль включены ссылки на требования следующих спецификаций, за исключением тех случаев, когда требования заменяются требованиями самого профиля:

•    Простой протокол доступа к объектам (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)

•    Язык описания веб-сервисов WSDL 1.1, Раздел 3.0 (WSDL 1.1, Section 3.0).

6

ГОСТ Р ИСО/МЭК 29363—2013

Приложение В

Возможные расширения

Этот раздел идентифицирует возможные расширения, как определено в «Области применения профиля» для спецификаций компонентов профиля.

Данные механизмы находятся вне области применения профиля; их использование может повлиять на функциональную совместимость и может потребовать частного соглашения сторон с веб-сервисами.

Расширения отсутствуют.

7