ГОСТ Р ИСО/МЭК 29361— 2012
SSL/TLS, HTTP) сделаны только в тех случаях, когда имеется конкретное влияние на сетевые услуги;
WS-I не пытается обеспечить интероперабельность этих протоколов в целом. Тем самым обеспечивается
эффективное использование экспертизы WS-I, сфокусированной на стандартах сетевых услуг.
1.5 Соглашения об обозначениях
В настоящем стандарте ключевые слова «ДОЛЖЕН». «НЕ ДОЛЖЕН» («MUST», «MUST NOT»),
«ТРЕБУЕМЫЙ» («REQUIRED»). «НУЖНО», «НЕ НУЖНО» («SHALL». «SHALL NOT»), «СЛЕДУЕТ». «НЕ
СЛЕДУЕТ» («SHOULD», «SHOULD NOT»). «РЕКОМЕНДУЕМЫЙ» («RECOMMENDED»), «МОЖЕТ» («MAY») и
«ФАКУЛЬТАТИВНЫЙ» {«OPTIONAL») должны пониматься в соответствии с RFC 2119”.
Нормативные утверждения требований в Профиле (т. е. те, которые влияют на соответствие, какопре
делено в «Требованияхсоответствия») представлены следующим образом:
RnnnnТекст утверждения.
где «пппп» заменяется уникальным вПрофиле номером требования, образующим уникальный идентифика
тор требования.
Идентификаторы требований могут рассматриваться какквалификаторы пространства имен так, чтобы
быть совместимыми с QNames в соответствии с Пространствами имен в XML2’. Когда явный префикс
пространства имен в идентификаторе требования отсутствует (например. «R9999» вместо «bp10:R9999»),
его следует интерпретировать как находящийся в пространстве имен, идентифицированном соответствую
щим URI раздела документа, в котором он встретился. Когда идентификатор квалифицирован, префикс
следует интерпретировать в соответствии с действующими отображениями пространств имен так, как
описано ниже.
Некоторые требования поясняют ссылочные спецификации, но не устанавливаютдополнительные
ограничения на реализации. Для удобства пояснения отмечены следующим образом: С
Некоторые требования получены на основе незавершенных работ по стандартизации ссылочныхспе
цификаций. Для удобства такие полученные с опережением утверждения отмечены следующим образом:
хххх. где «хххх» — идентификатор спецификации (например, «WSDL20» для WSDL, Версия 2.0). Посколь ку
на момент публикации настоящего стандарта указанные работы не завершены, спецификация, из кото рой
получено требование, может измениться; данная информация включена толькодля удобства реализа торов.
Точки расширения в поддерживающих спецификациях (см. раздел «Область соответствия») пред
ставлены аналогично:
ЕппппИмя точкирасширения— Описание.
где "пппп* заменяется уникальным для точек расширения в Профиле номером. Каки утверждения требова
ний, утверждения расширения можно рассматривать какквалификаторы пространства имен.
В настоящем стандарте использовано несколько префиксов пространств имен; ниже перечислены
соответствующие им URI. Выбор какого-либо префикса пространства имен является произвольным и не
имеетсемантического значения.
• soap —
"http://schemas.xmlsoap.org/soap/envelope/"
• xsi —
"http://www.w3.org/2001/XMLSchema-instance’
• xsd —
"http://www.w3.org/2001/XMLSchema"
• soaponc —
"http://schemas.xmlsoap.org/soap/encodingr
• wsdl —
"http://schemas.xmlsoap.org/wsdl/"
• soapbind — "
http://schemas.xmlsoap.orgAvsdl/soapr
• uddi — "um:uddi-org:api_v2"
1.6 Идентификация профиля и версии
Настоящий стандарт идентифицирован именем (Базовый Профиль) и номером версии (1.1). Вместе
они идентифицируют конкретный экземплярпрофиля.
Номер версии состоит из старшей и младшей части в виде «старшая.младшая». Он может быть
использован для определения предшествования экземпляров профиля: больший номер версии (состоя
щий из старшей и младшей частей) указывает на то, что экземпляр более новый и. следовательно,
заменяет более ранние.
1’
http://www.
ietf.org/rfc/rfc2119.txt.
21
http://www.w3.org.TR/REC-xml-names/.
3