Хорошие продукты и сервисы
Наш Поиск (введите запрос без опечаток)
Наш Поиск по гостам (введите запрос без опечаток)
Поиск
Поиск
Бизнес гороскоп на текущую неделю c 22.12.2025 по 28.12.2025
Открыть шифр замка из трёх цифр с ограничениями

ГОСТ Р ИСО/МЭК 40210-2014; Страница 19

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы ГОСТ Р ЕН 257-2004 Термостаты (терморегуляторы) механические для газовых аппаратов. Общие технические требования и методы испытаний Mechanical thermostats (thermoregulators) for gas appliances. General technical requirements and test methods (Настоящий стандарт устанавливает конструктивные и функциональные требования к механическим терморегуляторам для газовых аппаратов, определяет терминологию, маркировку и методы проведения испытаний. Стандарт распространяется на механические терморегуляторы, которые прямо или косвенно осуществляют регулирование температуры с помощью встроенного газового клапана и не нуждается в подводе электрической энергии от внешнего источника. Требования настоящего стандарта применимы к терморегуляторам всех газовых аппаратов, используемых для нагрева или охлаждения, работающих на природном и (или) сжиженном газах. Настоящий стандарт распространяется на терморегуляторы, которые встраивают в газовые аппараты, устанавливаемые в закрытом помещении) ГОСТ Р ИСО/МЭК 20000-3-2014 Информационная технология. Управление услугами. Часть 3. Руководство по определению области применения и применимости ИСО/МЭК 20000-1 (В данную часть стандарта ИСО/МЭК 20000 входит руководство по определению области применения и применимости документа ИСО/МЭК 20000-1, а также по демонстрации соответствия описанным в нем требованиям. Принципы, установленные в этой части стандарта ИСО/МЭК 20000, помогут поставщику услуг в планировании улучшения качества услуг и (или) в подготовке к оценке на соответствие требованиям документа ИСО/МЭК 20000-1. Настоящая часть стандарта ИСО/МЭК 20000 поможет определить, применим ли документ ИСО/МЭК 20000-1 к конкретным случаям, встречающимся у поставщиков услуг. В ней на примерах поясняется, как можно определить область применения SMS вне зависимости от того, имеет ли поставщик услуг опыт в определении областей применения других систем управления. В состав документа включено руководство по типам оценки соответствия и стандартам оценки) ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии. Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Элементы показателя качества (Настоящий стандарт содержит следующую информацию:. - требования к определению ЭПК как часть спецификации требований качества продукции с примерами [пункт 6.2 (таблицы 1 и 2)];. - начальное множество элементов ЭПК, приведенное в виде примеров [таблица A.1 (приложение A)];. - руководство для определения и количественной характеристики свойств продукции (согласно целевому назначению) для ЭПК (приложение B). Руководство предназначено для разработчиков, приобретателей и независимых оценщиков продукции, особенно тех, кто ответственен за определение требований и оценку качества продукции, но не ограничивается ими. Настоящий стандарт применим, если элементы показателей качества, которые предполагается использовать для формирования показателей качества, определены в соответствии с ИСО/МЭК 25022, ИСО/МЭК 25023 и ИСО/МЭК 25024)
Страница 19
Страница 1 Untitled document
ГОСТ Р ИСО/МЭК 402102014
Структура привязки не обеспечивает каких-либо средств для наименования или утилизирования
информации, включающей в себя состояние в данном узле. Отдельная функция и спецификация при
вязки могут вводить собственные соглашения для спецификации состояние. Следует отметить, однако,
что согласованность между привязками и функциями расширения, вероятно, будет лучше в тех ситу
ациях. когда спецификации нескольких функций принимают непротиворечивые соглашения для пред
ставления состояния. Например, несколько функций могли бы воспользоваться согласованной спе
цификацией для учетных данных аутентификации, идентификатора транзакции и т.д. Привязка HTTP в
Части 2 SOAP 1.2 [Часть 2 SOAP] иллюстрирует одно из таких соглашений.
Как описано в разделе 8, каждое сообщение SOAP определено как инфо-набор XML. который
состоит из информационного объекта document с одним и только одним дочерним элементом кон
вертом: информационным объектом элемента Envelope SOAP. Поэтому минимальная задача привязки
при передаче сообщения состоит в том, чтобы определить средства, которыми инфо-набор сообщения
SOAP передается и воссоздается привязкой на получающем узле SOAP, и определить, каким образом
осуществляется передача конверта с использованием функций нижележащего протокола.
В разделе 8 определено, что все конверты SOAP могут быть сериализованы с использованием
сериализации XML 1.0. Таким образом привязки МОГУТ в качестве представления для передачи (on the
wire) инфо-набора XML использовать XML 1.0 или более поздние версии. Однако структура при вязки
не требует, чтобы каждая привязка использовала бы сериализацию XML для передачи. Когда это
необходимо, могут использоваться сжатие, шифрование, фрагментированные представления и т.д. В
случае использования сериализации XML инфо-набора XML привязка МОЖЕТ потребовать использо
вания определенной кодировки символов или набора кодировок.
В случае использования сериализации XML для сериализации инфо-набора или делегирования
сериализации другим средствам (таким, как описание типа медиа) привязка должна перечислить ис
пользуемые версии XML. Для обеспечения функциональной совместимости список поддерживаемых
версий XML должен быть исчерпывающим.
Обработка сообщений в привязке МОЖЕТ обеспечить потоковую передачу. То есть узлы SOAP
МОГУТ начать обрабатывать полученное сообщение SOAP сразу же, как только доступна необходи
мая информация. Обработка SOAP определена в терминах инфо-наборов сообщения SOAP (см. раз
дел 8). Несмотря на то. что при потоковой передаче получатель SOAP принимает такие инфо-наборы
XML постепенно, результат обработки SOAP ДОЛЖЕН быть идентичным результату обработки в слу
чае. когда конверт SOAP полностью был доступен до начала обработки. Например, как предусмотре но
в пункте 5.6, идентификация предназначенных блоков заголовка SOAP и проверка всех атрибутов
mustUnderstand должны быть сделаны прежде, чем будет продолжена дальнейшая обработка. В зави
симости от представления, используемого для инфо-набора XML и порядка, в котором он передается,
данное правило может ограничить характеристику потока передачи, которая может быть достигнута.
Привязка МОЖЕТ зависеть от состояния, которое моделируется за пределами инфо-набора со
общения SOAP (например, счетчики повторной передачи), и МОЖЕТ передавать такую информацию
смежным узлам. Например, некоторая привязка может принимать адрес доставки сообщения (обычно
URI), которого нет в конверте.
8 Логическая структура сообщения SOAP
Сообщение SOAP определено как инфо-набор XML. в котором информационные объекты ком
ментариев. элементов, атрибутов, пространств имен и символов (character) могут быть сериализованы
как XML 1.0. Необходимо отметить, что требование возможности сериализации указанных информа
ционных элементов инфо-наборов сообщения SOAP как XML 1.0 НЕ ЯВЛЯЕТСЯ требованием сериа
лизации с использованием XML 1.0. Инфо-набор сообщения SOAP содержит информационный объ ект
document с одним и только одним элементом в его свойстве [children], которое ДОЛЖНО быть
информационным объектом элемента Envelope SOAP (см. пункт 8.1). Этот информационный объект
является также и значением свойства [document element]. Свойства [notations] и [unparsed entities] оба
пусты. Рекомендация «Информационный набор XML» [XML InfoSet] допускает контент, который не мо жет
быть непосредственно сериализован с использованием XML: например, символ #х0 допускается в инфо-
наборе, но запрещен в XML. XML инфо-набор сообщения SOAP ДОЛЖЕН соответствовать тре бованиям
сериализации XML 1.0 [XML 1.0].
Инфо-набор XML сообщения SOAP НЕ ДОЛЖЕН содержать информационный объект декларации
типа документа (document type declaration).
15