ГОСТ Р ИСО/МЭК 19770-2-2014
стандарт или стандарт де-факто, определяющий дополнительную уникальную идентификационную
информацию об оборудовании и платформе, то для разработки согласованного элемента installation_
target_kl, который можно будет использовать на любой платформе, должны будут использоваться ого
воренные в этом стандарте данные. Если некоторые типы идентификационной информации об обору
довании станут официальным стандартом, предполагается, что информация из этого стандарта будет
включена в раздел соответствия будущей версии данной части настоящего стандарта.
8 Элементы
8.1 Общие положения
Элементы описывают общие атрибуты всех или большинства элементов конфигурации программ
ного обеспечения. Операционные системы и инструментарий для обнаружения тегов могут использо
вать эти атрибуты для идентификации элементов конфигурации программного обеспечения.
Элементы могут изменяться различными модификаторами тегов (см. 6.2.3, 6.2.4).
В данной части настоящего стандарта перечислены 37 элементов (список элементов не полный).
Эти элементы являются предопределенными, чтобы обеспечить согласованность между тегами иден
тификации программного обеспечения (см. 8.2).
Описания элементов, приведенные в 8.3 и 8.4, соответственно, сопровождаются примерами. При
меры приводятся в XML-синтаксисе, формат которогодолжен использоваться при создании тегов иден
тификации программного обеспечения. Примеры показывают, какая информация должна быть включе на
в элементы данных. Расширенные примеры тегов идентификации программного обеспечения при
ведены в приложении Н.
Данная часть настоящего стандарта не требует наличия конкретного процесса формирования со
держания элементов.
Обязательные элементы (см. 8.3) требуются для признания тега идентификации программного
обеспечения действительным или полным. Инструментарий для обнаружения тегов должен распозна
вать неполные теги идентификации программного обеспечения как недействительные и уведомлять
специалиста-практика по использованию процессов SAM. отвечающего за теги идентификации про
граммного обеспечения, о том, что эти теги не являются действительными или полными. Всего имеется
пять обязательных элементов.
Рекомендуется, чтобы поставщики тегов имели централизованное хранилище всех тегов иденти
фикации программного обеспечения, созданных для всех релизов продуктов, в котором хранились бы,
по крайней мере, обязательные элементы. Такое хранилище можно будет использовать для проверки
уникальности идентификаторов GUID. а также для обеспечения того, что имя создателя программно го
обеспечения и идентификатор GUID остаются согласованными по всей линейке продуктов. Данная часть
настоящего стандарта не требует привлечения внешнего регистрирующего органа для работы с тегами
идентификации программного обеспечения, поэтому уникальность или неуникальность конкрет ного тега
определяет сам создатель тега.
Дополнительные элементы (см. 8.4) могут быть, а могут не быть представлены в теге идентифи
кации программного обеспечения. Элементы данных, соответствующие дополнительным элементам,
наделяют создателей тегов идентификации программного обеспечения дополнительной функциональ
ностью. что позволяет повысить надежность информации, с которой работают специалисты-практики
по использованию процессов SAM и поставщики инструментария. Такие дополнительные элементы
необходимо использовать в соответствии с требованиями данного раздела.
В теге идентификации программного обеспечения могут присутствовать расширенные элемен
ты (см. 8.5), для того чтобы разрешить включение дополнительных значений, которые ранее не были
предопределены. Расширенные элементы должны иметь формат XML и должны включать ссылку XSD,
которую можно использоватьдля проверки информации, содержащейся в этом разделе.
В отличие от обязательного и дополнительного разделов, которых может быть только один, в теге
могут присутствовать несколько расширенных разделов. Каждый расширенный раздел должен быть
привязан к конкретному создателю или модификатору тега и не должен разрешать смешанное исполь
зование. Например, создатель тега может пожепать включить расширенные элементы в собственный
инструментарий для обнаружения тегов. Организация потребителя программного обеспечения может
пожелать включить внешние элементы, относящиеся общим политикам и процедурам обеспечения
жизненного цикла программного обеспечения.
27