ECMA-376, Part 2, 5th edition (2021) · Office Open XML. Часть 2: Правила упаковки Open Packaging Conventions (ECMA-376, часть 2, 5-е издание, декабрь 2021 г.)

Неофициальный полный русский перевод ECMA-376, часть 2, 5-е издание (декабрь 2021). Первоисточник: Ecma International. Официальная английская версия имеет преимущественную силу. Перевод не объявляется переводом ISO.

ECMA-376, 5-е издание

Форматы файлов Office Open XML — соглашения об открытой упаковке

Декабрь 2021 г.

Содержание

• Предисловие — vii
• Введение — ix
• 1 Область применения — 1
• 2 Нормативные ссылки — 2
• 3 Термины и определения — 4
• 4 Соответствие — 8
• 5 Обзор — 9
• 6 Абстрактная модель пакета — 10
  • 6.1 Общие положения — 10
  • 6.2 Части пакета — 10
    • 6.2.1 Общие положения — 10
    • 6.2.2 Имена частей пакета — 10
    • 6.2.3 Типы носителей — 12
    • 6.2.4 Подсказка роста — 12
    • 6.2.5 Использование XML — 12
  • 6.3 Адресация частей пакета — 13
    • 6.3.1 Общие положения — 13
    • 6.3.2 Схема pack — 13
    • 6.3.3 Разрешение IRI pack в ресурс — 14
    • 6.3.4 Формирование IRI pack — 15
    • 6.3.5 Эквивалентность — 16
  • 6.4 Разрешение относительных ссылок — 16
    • 6.4.1 Общие положения — 16
    • 6.4.2 Базовые IRI — 16
    • 6.4.3 Примеры — 17
  • 6.5 Связи — 19
    • 6.5.1 Общие положения — 19
    • 6.5.2 Часть Relationships — 20
    • 6.5.3 Разметка связей — 21
    • 6.5.4 Примеры — 23
• 7 Физическая модель пакета — 27
  • 7.1 Общие положения — 27
  • 7.2 Руководящие указания по физическому отображению — 27
    • 7.2.1 Использование возможностей физических форматов — 27
    • 7.2.2 Отображённые компоненты — 27
    • 7.2.3 Отображение типов носителей на части пакета — 27
    • 7.2.4 Перемежение — 31
    • 7.2.5 Отображение имён частей пакета на имена элементов физического пакета — 32
  • 7.3 Отображение в ZIP-файл — 33
    • 7.3.1 Общие положения — 33
    • 7.3.2 Отображение данных части пакета — 34
    • 7.3.3 Имена элементов ZIP — 34
    • 7.3.4 Отображение имён логических элементов на имена элементов ZIP — 34
    • 7.3.5 Отображение имён элементов ZIP на имена логических элементов — 35
    • 7.3.6 Ограничения ZIP-пакета — 35
    • 7.3.7 Отображение потока Media Types — 35
    • 7.3.8 Отображение подсказки роста — 36
• 8 Основные свойства — 37
  • 8.1 Общие положения — 37
  • 8.2 Часть Core Properties — 38
  • 8.3 Разметка основных свойств — 38
    • 8.3.1 Общие положения — 38
    • 8.3.2 Поддержка управления версиями и расширяемости — 39
    • 8.3.3 элемент coreProperties — 39
    • 8.3.4 Элементы основных свойств — 39
• 9 Миниатюры — 44
• 10 Цифровые подписи — 45
  • 10.1 Общие положения — 45
  • 10.2 Обзор ограничений и расширений, специфичных для OPC, для «Синтаксиса и обработки XML-подписей» — 45
  • 10.3 Выбор содержимого для подписания — 45
  • 10.4 Части цифровой подписи — 45
    • 10.4.1 Общие положения — 45
    • 10.4.2 Часть источника цифровой подписи — 46
    • 10.4.3 Часть XML-подписи цифровой подписи — 46
    • 10.4.4 Часть сертификата цифровой подписи — 46
  • 10.5 Разметка цифровой подписи — 47
    • 10.5.1 Общие положения — 47
    • 10.5.2 Поддержка управления версиями и расширяемости — 47
    • 10.5.3 элемент Signature — 47
    • 10.5.4 элемент SignedInfo — 48
    • 10.5.5 элемент CanonicalizationMethod — 48
    • 10.5.6 элемент SignatureMethod — 48
    • 10.5.7 элемент Reference — 49
    • 10.5.8 элемент Transform — 49
    • 10.5.9 элемент RelationshipReference — 50
    • 10.5.10 элемент RelationshipsGroupReference — 50
    • 10.5.11 элемент DigestMethod — 51
    • 10.5.12 элемент Object — 51
    • 10.5.13 элемент Manifest — 51
    • 10.5.14 элемент SignatureProperty — 52
    • 10.5.15 элемент SignatureTime — 52
    • 10.5.16 элемент Format — 52
    • 10.5.17 элемент Value — 52
    • 10.5.18 элемент XPath — 52
  • 10.6 Алгоритм преобразования связей — 52
  • 10.7 Пример цифровой подписи — 54
  • 10.8 Формирование подписей — 56
  • 10.9 Проверка подписей — 58

• Приложение A (справочное) Предварительная обработка для формирования относительных ссылок — 61
• Приложение B (нормативное) Ограничения и уточнения по использованию возможностей ZIP — 63
  • B.1 Общие положения — 63
  • B.2 Согласованность заголовка архивного файла — 63
  • B.3 Сигнатура дескриптора данных — 63
  • B.4 Требования к реализаторам пакетов — 63
• Приложение C (нормативное) Схемы — W3C XML — 74
  • C.1 Общие положения — 74
  • C.2 Поток Media Types — 74
  • C.3 Часть Core Properties — 74
  • C.4 Разметка XML-подписи цифровой подписи — 74
  • C.5 Часть Relationships — 74
• Приложение D (справочное) Схемы — RELAX NG — 75
  • D.1 Общие положения — 75
  • D.2 Поток Media Types — 75
  • D.3 Часть Core Properties — 75
  • D.4 Разметка XML-подписи цифровой подписи — 75
  • D.5 Часть Relationships — 75
  • D.6 Дополнительные ресурсы — 75
    • D.6.1 XML — 75
    • D.6.2 Ядро XML-цифровой подписи — 75
• Приложение E (нормативное) Стандартные пространства имён и типы носителей — 76
• Приложение F (справочное) Проектные соображения физической модели пакета — 78
  • F.1 Общие положения — 78
  • F.2 Стили доступа — 79
    • F.2.1 Общие положения — 79
    • F.2.2 Потребление с прямым доступом — 79
    • F.2.3 Потоковое потребление — 79
    • F.2.4 Потоковое создание — 79
    • F.2.5 Одновременное создание и потребление — 79
  • F.3 Стили компоновки — 80
    • F.3.1 Общие положения — 80
    • F.3.2 Простое упорядочение — 80
    • F.3.3 Перемежаемое упорядочение — 80
  • F.4 Стили передачи — 81
    • F.4.1 Общие положения — 81
    • F.4.2 Последовательная доставка — 81
    • F.4.3 Произвольный доступ — 81
• Приложение G (справочное) Различия между ECMA-376-2021 и ECMA-376:2006 — 82
  • G.1 Общие положения — 82
  • G.2 Элементы XML — 82
  • G.3 Атрибуты XML — 82
  • G.4 Значения перечислений XML — 82
  • G.5 Простые типы XML — 82
  • G.6 Имена частей пакета — 82

• Приложение H (справочное) Пример пакета — 83
  • H.1 Общие положения — 83
  • H.2 Абстрактный пакет — 83
  • H.3 Физический пакет — 84
• Библиография — 85

Предисловие

Настоящее издание отменяет и заменяет предыдущее издание (ECMA-376-2:2012), которое было технически пересмотрено.

Основные изменения по сравнению с предыдущим изданием заключаются в следующем:

• Там, где это уместно, нормативные ссылки были обновлены для использования недатированных или более поздних версий других стандартов.
• Раздел 3 (Термины и определения) пересмотрен путём удаления терминов, не используемых ни в одном нормативном разделе, и последующей реорганизации терминов в группы.
• Подраздел, посвящённый примечаниям к диаграммам (5.1 в предшествующих изданиях), удалён, поскольку основные свойства теперь определяются текстом и схемами, а не диаграммами.
• Раздел об акронимах и сокращениях (раздел 6 в предшествующих изданиях) удалён, поскольку для стандарта ISO/IEC не имеет смысла определять «ISO» и «IEC».
• Раздел 6 (Абстрактная модель пакета, раздел 8 в предыдущем издании) полностью переработан. В частности, (1) IRI pack определены в этом разделе, а не в приложении; (2) добавлен новый подраздел «Разрешение относительных ссылок»; (3) разграничены части Relationships частей пакета и части Relationships пакета; (4) чётко определены базовые IRI; и (5) на основе RFC 3987 уточнена обработка символов, не относящихся к ASCII, в именах частей пакета.
• Удалена возможность задавать тип носителя пустой строкой, поскольку это противоречит определению типа носителя в RFC 2046 и существующему регулярному выражению, определённому в схеме, на которую ссылается C.2.
• Раздел 7 (Физическая модель пакета, раздел 9 в предыдущем издании) слегка пересмотрен. Перемежение введено перед именами логических элементов. В 7.3.4 и 7.3.5 явно введены процентное кодирование и процентное декодирование символов, не относящихся к ASCII.
• Раздел 8 (Основные свойства, раздел 10 в предыдущем издании) переработан с использованием текста и схем вместо диаграмм.
• Раздел 10 (Цифровые подписи, раздел 12 в предыдущем издании) тщательно пересмотрен. В частности, этот раздел теперь уточняет соглашение о выборе алгоритмов для методов подписи и дайджеста, которое отражает продолжающееся развитие алгоритмов со времени первого издания настоящего документа.
• Приложение A сделано справочным.
• Нормативное приложение, определявшее IRI pack (приложение B в предшествующих изданиях), исключено. IRI pack теперь определены в разделе 6.
• Приложения C и D (приложения D и E в предшествующих изданиях) более не определяют схемы, а ссылаются на внешне определённые схемы.
• Руководящие указания по выполнению требований соответствия (приложение H в предшествующих изданиях) исключены.
• Требования, относящиеся к потоковому потреблению, исключены.
• Где возможно, требования к программам переписаны как требования к данным.

• Добавлено приложение H, изображающее пример пакета.
• Указатель (приложение J в предшествующих изданиях) удалён.
• Добавлена библиография.

Введение

ECMA-376 (все части стандарта) устанавливает семейство схем XML, совместно именуемых Office Open XML, которые определяют словари XML для документов текстовой обработки, электронных таблиц и презентаций, а также упаковку документов, соответствующих этим схемам.

Цель состоит в том, чтобы обеспечить реализацию форматов Office Open XML максимально широким набором средств и платформ, содействуя функциональной совместимости между приложениями для повышения офисной производительности и системами, поддерживающими бизнес-процессы, а также поддержать и укрепить архивирование и сохранение документов — всё это способом, полностью совместимым с существующим массивом документов Microsoft® Office¹.

Настоящий документ включает два приложения (приложения C и D), которые ссылаются на файлы данных, предоставленные в электронной форме.

Форматы представления документов, определённые настоящим документом, отличаются от форматов, определённых в соответствующей части стандарта ECMA-376:2006. Некоторые различия отражены в изменениях схем, как показано в приложении G.

Настоящее пятое издание сохраняет всю прежнюю функциональность и не добавляет новой функциональности.

¹ Эта информация приводится для удобства пользователей настоящего документа и не означает одобрения Ecma названного продукта. Могут использоваться эквивалентные продукты, если можно показать, что они приводят к тем же результатам.

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

Настоящий документ определяет набор соглашений для упаковки одного или нескольких взаимосвязанных потоков байтов (частей пакета) в единый ресурс (пакет). Эти соглашения применимы не только к спецификациям Office Open XML, описанным в ECMA-376-1 и ECMA-376-4, но и к другим спецификациям разметки.

2 Нормативные ссылки

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

ANSI/INCITS 4-1986 [R2017] - Information Systems - Coded Character Sets - 7-Bit American National Standard Code For Information Interchange (7-Bit ASCII), American National Standards Institute (ANSI). 2017

FIPS 186-4, Digital Signature Standard (DSS), National Institute of Standards and Technology, US Department of Commerce, July 2013

ECMA-376-3, Information technology — Document description and processing languages — Office Open XML File Formats, Part 3: Markup Compatibility and Extensibility

ISO/IEC 9594-8/ITU-T Rec. X.509, Information technology — Open systems interconnection — Part 8— The Directory: Public-key and attribute certificate frameworks

ISO 15836-1, Information and documentation — The Dublin Core metadata element set — Part 1: Core elements

ISO 15836-2, Information and documentation — The Dublin Core metadata element set — Part 2: DCMI Properties and classes

RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, The Internet Society, November 1996, N. Freed and N. Borenstein. Доступно по адресу https://www.rfc-editor.org/info/rfc2046

RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, The Internet Society, January 2005, Berners-Lee, T., R. Fielding, and L. Masinter. Доступно по адресу https://www.rfc-editor.org/info/rfc3986

RFC 3987, Internationalized Resource Identifiers (IRIs), The Internet Society, January 2005, Duerst, M. and M. Suignard. Доступно по адресу https://www.rfc-editor.org/info/rfc3987

RFC 5234, Augmented BNF for Syntax Specifications: ABNF, The Internet Society, January 2008, D. Crocker and P.Overell, (editors). Доступно по адресу https://www.rfc-editor.org/info/rfc5234

RFC 6931, Additional XML Security Uniform Resource Identifiers (URIs), The Internet Society, April 2013, D. Eastlake 3^rd. Доступно по адресу https://www.rfc-editor.org/info/rfc6931

RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, The Internet Society, June 2014, R. Fielding and J. Reschke. Доступно по адресу https://www.rfc-editor.org/info/rfc7231

Unicode, The Unicode Standard, The Unicode Consortium. Доступно по адресу http://www.unicode.org/standard/standard.html

Спецификация XML 1.0, Extensible Markup Language (XML) 1.0, Fourth Edition. World Wide Web Consortium, 2006, Tim Bray, Jean Paoli, Eve Maler, C. M. Sperberg-McQueen, and François Yergeau (editors). Доступно по адресу http://www.w3.org/TR/2006/REC-xml-20060816/²

XML Namespaces, Namespaces in XML 1.0 (Third Edition), 8 December 2009. World Wide Web Consortium, Tim Bray, Dave Hollander, Andrew Layman, and Richard Tobin (editors). Доступно по адресу http://www.w3.org/TR/2009/REC-xml-names-20091208/

XML Base, XML Base (Second Edition), World Wide Web Consortium, 28 January 2009. Jonathan Marsh and Richard Tobin (editors). Доступно по адресу https://www.w3.org/TR/2009/REC-xmlbase-20090128/

W3C XML Schema Structures, XML Schema Part 1: Structures (Second Edition), World Wide Web Consortium, 28 October 2004, Henry Thompson, David Beech, Murray Maloney and Noah Mendelsohn (editors). Доступно по адресу https://www.w3.org/TR/xmlschema-1/

W3C XML Schema Datatypes, XML Schema Part 2: Datatypes (Second Edition), World Wide Web Consortium, 28 October 2004, Paul Biron and Ashok Malhotra (editors). Доступно по адресу https://www.w3.org/TR/xmlschema-2/

XML-Signature Syntax and Processing, World Wide Web Consortium, 12 February 2002, Donald Eastlake, Joseph Reagle and David Solo (editors). Доступно по адресу http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/

ZIP Appnote, ZIP File Format Specification Version 6.2.0, PKWARE Inc., 2004. Доступно по адресу http://www.pkware.com/documents/APPNOTE/APPNOTE_6.2.0.txt

²Дальнейшая корректировка нормативной ссылки на XML с указанием 5-го издания потребуется, когда связанные справочные спецификации, на которые настоящий документ также даёт нормативную ссылку и которые также зависят от XML, такие как XML Namespaces и XML Base, будут все согласованы с 5-м изданием.

3 Термины и определения

Для целей настоящего документа применяются следующие термины и определения.

3.1 Основные понятия

3.1.1
байт

последовательность из 8 битов, рассматриваемая как единое целое

3.1.2
поток

линейно упорядоченная последовательность байтов (3.1.1)

3.2 Абстрактная модель пакета

3.2.1
часть пакета

поток (3.1.2) с именем, MIME-типом носителя и связанными общими свойствами

3.2.2
абстрактный пакет

логическая сущность, содержащая коллекцию частей пакета (3.2.1) и связей (3.2.3)

3.2.3
связь

связь пакета (3.2.4) или связь части пакета (3.2.5)

3.2.4
связь пакета

соединение от пакета к конкретной части пакета (3.2.1) в том же пакете либо к внешнему ресурсу

3.2.5
связь части пакета

соединение от части пакета (3.2.1) в пакете к другой части пакета в том же пакете либо к внешнему ресурсу

3.2.6
источник

часть пакета (3.2.1) или пакет, от которого устанавливается соединение посредством связи (3.2.3)

3.2.7
цель

часть пакета (3.2.1) или внешний ресурс, к которому устанавливается соединение посредством связи (3.2.3)

3.2.8
тип связи

абсолютный IRI для задания роли связи (3.2.3)

3.2.9
часть Relationships

часть пакета (3.2.1), содержащая XML-представление связей (3.2.3)

3.2.10
абстрактная модель пакета

абстрактная модель, определяющая абстрактные пакеты (3.2.2)

3.2.11
подсказка роста

предлагаемое число байтов (3.1.1) для резервирования для части пакета (3.2.1), чтобы она могла увеличиваться на месте

3.2.12
схема pack

схема URI, позволяющая использовать IRI как единообразный механизм адресации частей пакета (3.2.1) внутри пакета

3.2.13
IRI pack

IRI, соответствующий схеме pack (3.2.12)

3.2.14
имя части пакета

строка, однозначно идентифицирующая часть пакета (3.2.1) внутри пакета

3.2.15
идентификатор связи

строка, состоящая из символов имени XML и однозначно идентифицирующая связь (3.2.3) среди связей от одного и того же источника (3.2.6)

3.2.16
режим цели

режим разрешения относительных ссылок на цели (3.2.7)

3.2.17
сегмент I18N

строка Unicode в имени части пакета (3.2.14)

Примечание 1 к термину: ограничения на значение строки Unicode ДОЛЖНЫ (SHALL) быть указаны при использовании термина в 6.2.2.2.

3.3 Физическая модель пакета

3.3.1
физический формат

конкретный формат файла либо иной механизм постоянного хранения или передачи

3.3.2
физический пакет

результат отображения абстрактного пакета (3.2.2) в физический формат (3.3.1)

3.3.3
физическая модель пакета

пара, состоящая из физического формата (3.3.1) и отображения между абстрактной моделью пакета (3.2.10) и этим физическим форматом

3.3.4
фрагмент

часть части пакета (3.2.1)

3.3.5
логический элемент

неперемежаемая часть пакета (3.2.1), неперемежаемый поток Media Types (3.3.12), фрагмент (3.3.4) перемежаемой части пакета или фрагмент перемежаемого потока Media Types

3.3.6
элемент физического пакета

атомарный набор данных в физическом пакете (3.3.2)

3.3.7
элемент ZIP

атомарный набор данных в ZIP-файле (3.3.8), который становится файлом при распаковке архива

3.3.8
ZIP-файл

файл, определённый в ZIP Appnote

3.3.9
простое упорядочение

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

3.3.10
перемежаемое упорядочение

определённый порядок размещения частей пакета (3.2.1) в пакете, при котором части пакета разбиваются на фрагменты (3.3.4) и «перемешиваются» с фрагментами других частей пакета

3.3.11
ASCII-независимое от регистра сопоставление

сравнение последовательности кодовых точек так, как если бы все кодовые точки ASCII в диапазоне от 0x41 до 0x5A (от A до Z) были отображены на соответствующие кодовые точки в диапазоне от 0x61 до 0x7A (от a до z)

Примечание 1 к термину: кодовые точки ASCII ДОЛЖНЫ (SHALL) быть определены в соответствии с ANSI/INCITS 4-1986.

3.3.12
поток Media Types

поток (3.1.2) в физическом пакете (3.3.2), представляющий XML-документ, задающий тип носителя каждой части пакета (3.2.1) в пакете

3.4 Цифровая подпись и миниатюра

3.4.1
политика подписи

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

3.4.2
миниатюра

небольшое изображение, являющееся графическим представлением части пакета (3.2.1) или пакета в целом

3.5 Реализации

3.5.1
реализатор пакета

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

3.6 Основные свойства

3.6.1
основное свойство

свойство пакета

4 Соответствие

Пакет относится к классу соответствия OPC, если он соблюдает все синтаксические ограничения, заданные в настоящем документе.

Соответствие OPC носит исключительно синтаксический характер.

5 Обзор

Настоящий документ описывает абстрактную модель пакета (раздел 6) и физическую модель пакета (раздел 7) для использования XML, Unicode, ISO/IEC 10646 (см. ссылку [7]), ZIP и других относящихся к делу технологий и спецификаций для организации содержимого и ресурсов документа внутри пакета. Структура пакета предназначена для поддержки организации составляющих ресурсов для различных приложений и категорий содержимого. Пример пакета приведён в приложении H.

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

Физическая модель пакета определяет отображение компонентов абстрактной модели пакета на возможности конкретного физического формата, а именно ZIP-файла.

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

Настоящий документ устанавливает требования к пакетам. Требования соответствия указаны по всему настоящему документу. Формальное положение о соответствии приведено в разделе 4.

6 Абстрактная модель пакета

6.1 Общие положения

В настоящем разделе вводятся абстрактные пакеты в терминах частей пакета (6.2) и связей (6.5). В нём также вводится схема pack (6.3.2).

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

Пример абстрактного пакета приведён в H.2.

6.2 Части пакета

6.2.1 Общие положения

Часть пакета аналогична файлу в файловой системе или ресурсу на HTTP-сервере.

6.2.2 Имена частей пакета

6.2.2.1 Общие положения

Часть пакета ДОЛЖНА (SHALL) иметь имя части пакета, которое ДОЛЖНО (SHALL) однозначно идентифицировать часть пакета в абстрактном пакете.

6.2.2.2 Синтаксис

Имя части пакета ДОЛЖНО (SHALL) быть строкой Unicode, соответствующей следующим правилам продукции в синтаксисе ABNF, определённом в RFC 5234:

part_name = 1*( "/" isegment-nz ) 
isegment-nz = <isegment-nz, see RFC3987, Section 2.2> 

и дополнительно удовлетворять перечисленным ниже ограничениям, где сегмент I18N — это строка Unicode, соответствующая нетерминалу isegment-nz, а процентное кодирование представляет символ знаком процента «%», за которым следуют две шестнадцатеричные цифры, как указано в RFC 3986.

• Ни один сегмент I18N НЕ ДОЛЖЕН (SHALL NOT) содержать процентно закодированные символы прямой косой черты («/») или обратной косой черты («\»).
• Ни один сегмент I18N НЕ ДОЛЖЕН (SHALL NOT) содержать процентно закодированные символы, соответствующие нетерминалу iunreserved в RFC 3987.
• Ни один сегмент I18N НЕ ДОЛЖЕН (SHALL NOT) оканчиваться символом точки («.»).

Имя части пакета «/_rels/.rels» ДОЛЖНО (SHALL) быть зарезервировано (6.5.2.2). Имена частей пакета, в которых предпоследний сегмент I18N эквивалентен «_rels», а последний сегмент эквивалентен любой строке, оканчивающейся на «.rels», ДОЛЖНЫ (SHALL) быть зарезервированы (6.5.2.3).

ПРИМЕР 1 Имя части пакета «/hello/world/doc.xml» содержит три сегмента пути, а именно «hello», «world» и «doc.xml».

ПРИМЕР 2 Имя части пакета «/é» содержит сегмент пути «é», где é — «LATIN SMALL LETTER E WITH ACUTE» (U+00E9).

ПРИМЕЧАНИЕ Сегменты пути не представлены явно как папки в абстрактной модели пакета, и в абстрактной модели пакета не существует каталога папок.

Реализатор пакета не обязан поддерживать имена частей пакета, не входящие в ASCII, хотя это рекомендуется.

6.2.2.3 Эквивалентность и целостность имён частей пакета в абстрактном пакете

Эквивалентность имён частей пакета ДОЛЖНА (SHALL) определяться ASCII-независимым от регистра сопоставлением. Такое сопоставление сравнивает последовательность кодовых точек так, как если бы все кодовые точки ASCII в диапазоне 0x41–0x5A (A–Z) были отображены на соответствующие кодовые точки в диапазоне 0x61–0x7A (a–z). См. ссылку [1].

Имена двух различных частей пакета в абстрактном пакете НЕ ДОЛЖНЫ (SHALL NOT) быть эквивалентными.

ПРИМЕР 1 Если абстрактный пакет содержит часть пакета с именем «/a», имя другой части пакета в этом абстрактном пакете не может быть «/a» или «/A».

Для каждого имени части пакета N и строки S обозначим результат конкатенации N, прямой косой черты и S как N[S]. Говорят, что имя части пакета N1 выводимо из другого имени части пакета N2, если для некоторой строки S N1 эквивалентно N2[S].

ПРИМЕР 2 «/a/b» выводимо из «/a», где N — «/a», а S — «b».

Имя части пакета НЕ ДОЛЖНО (SHALL NOT) быть выводимым из имени другой части пакета.

ПРИМЕР 3 Предположим, что абстрактный пакет содержит часть пакета с именем «/segment1/segment2/…/segmentn». Чтобы оно не было выводимым, другие части пакета в этом абстрактном пакете не могут иметь такие имена, как «/segment1», «/SEGMENT1», «/segment1/segment2», «/segment1/SEGMENT2» или «/segment1/segment2/…/segmentn-1».

В этом подразделе также вводятся рекомендации, чтобы формы нормализации Unicode C (NFC) и Unicode D (NFD) имён частей пакета не приводили к коллизиям имён частей пакета. Следует учитывать, что некоторые реализации структур каталогов всегда применяют нормализацию NFD.

Применение нормализации NFC или NFD к именам двух различных частей пакета в абстрактном пакете НЕ СЛЕДУЕТ (SHOULD NOT) приводить к эквивалентным строкам.

Если абстрактный пакет содержит часть пакета с именем «/é», где é — «LATIN SMALL LETTER E» (U+0065), за которой следует «COMBINING ACUTE ACCENT» (U+0301), имя другой части пакета в этом абстрактном пакете НЕ СЛЕДУЕТ (SHOULD NOT) иметь вид

«/é», где é — «LATIN SMALL LETTER E WITH ACUTE» (U+00E9), или «/É», где É — «LATIN CAPITAL LETTER E WITH ACUTE» (U+00C9).

Если абстрактный пакет содержит часть пакета с именем «/Å», где Å — «ANGSTROM SIGN» (U+212B), имя другой части пакета в этом абстрактном пакете НЕ СЛЕДУЕТ (SHOULD NOT) иметь вид «/Å», где Å — «LATIN CAPITAL LETTER A WITH RING ABOVE» (U+00C5), поскольку U+212B и U+00C5 нормализуются к одной и той же последовательности символов.

Говорят, что имя части пакета N1 слабо выводимо из другого имени части пакета N2, если для некоторой строки S результат применения NFC или NFD к N1 эквивалентен результату применения NFC или NFD к N2[S].

ПРИМЕР 4 Рассмотрим имя части пакета «/é», где é — «LATIN SMALL LETTER E WITH ACUTE» (U+00E9). Другое имя части пакета «/é/a», где é — «LATIN SMALL LETTER E» (U+0065), за которой следует «COMBINING ACUTE ACCENT» (U+0301), слабо выводимо из «/é». Другое имя части пакета «/É/a», где É — «LATIN CAPITAL LETTER E» (U+0045), за которой следует «COMBINING ACUTE ACCENT» (U+0301), также слабо выводимо.

Имя части пакета НЕ СЛЕДУЕТ (SHOULD NOT) быть слабо выводимым из имени другой части пакета.

Предположим, что абстрактный пакет содержит часть пакета с именем «/é/Å/foo», где é — «LATIN SMALL LETTER E WITH ACUTE» (U+00E9), а Å — «ANGSTROM SIGN» (U+212B). Чтобы оно не было слабо выводимым, другие части пакета в этом абстрактном пакете НЕ СЛЕДУЕТ (SHOULD NOT) называть, например, «/É» и «/É/Å», где É — «LATIN CAPITAL LETTER E» (U+0045), за которой следует «COMBINING ACUTE ACCENT» (U+0301), а Å — «LATIN CAPITAL LETTER A WITH RING ABOVE» (U+00C5).

6.2.3 Типы носителя

Каждая часть пакета ДОЛЖНА (SHALL) иметь MIME-тип носителя, определённый в RFC 2046, для идентификации типа содержимого этой части пакета; он состоит из типа носителя верхнего уровня и подтипа, при необходимости уточнённых набором параметров. Типы носителя OPC-специфичных частей пакета, определённых в настоящем документе, НЕ ДОЛЖНЫ (SHALL NOT) содержать параметры.

Типы носителя для частей пакета, определённых в настоящем документе, перечислены в приложении E.

6.2.4 Подсказка роста

Часть пакета МОЖЕТ (MAY) иметь подсказку роста.

Иногда часть пакета в физическом пакете изменяется и должна стать больше. Для некоторых физических форматов создание нового физического пакета, содержащего увеличенную часть пакета, является дорогостоящей операцией. Чтобы позволить части пакета увеличиваться на месте, перемещая как можно меньше байтов, подсказка роста МОЖЕТ (MAY) использоваться для резервирования места при отображении в конкретный физический формат.

6.2.5 Использование XML

Содержимое XML в частях пакета и потоках, определённых в настоящем документе (в частности, поток Media Types, часть Core Properties, части XML Signature цифровой подписи и части Relationships), ДОЛЖНО (SHALL) соответствовать следующему:

a) Содержимое XML ДОЛЖНО (SHALL) быть закодировано с использованием UTF-8 или UTF-16. Если какая-либо часть пакета содержит декларацию кодировки, определённую в 4.3.3 спецификации XML 1.0, эта декларация НЕ ДОЛЖНА (SHALL NOT) указывать кодировку, отличную от UTF-8 или UTF-16.

b) Спецификация XML 1.0 допускает использование определений типа документа (DTD), которые позволяют осуществлять атаки отказа в обслуживании, обычно посредством метода раскрытия внутренних сущностей. Для снижения этой потенциальной угрозы декларации DTD НЕ ДОЛЖНЫ (SHALL NOT) использоваться в XML-разметке, определённой в настоящем документе.

c) XML-документы ДОЛЖНЫ (SHALL) соответствовать пространствам имён XML.

d) Содержимое XML ДОЛЖНО (SHALL) быть допустимым по схеме, как определено W3C XML Schema Structures и W3C XML Schema Datatypes, относительно соответствующей схемы XSD, определённой в приложении C настоящего документа. В частности, содержимое XML НЕ ДОЛЖНО (SHALL NOT) содержать элементы или атрибуты из пространств имён, которые явно не определены в соответствующей схеме XSD, если только схема XSD не допускает присутствия элементов или атрибутов из любого пространства имён в определённых местах XML-разметки.

e) Содержимое XML НЕ ДОЛЖНО (SHALL NOT) содержать элементы или атрибуты из пространств имён «xml» или «xsi», если только они явно не определены в схеме XSD или иными средствами, описанными в настоящем документе.

6.3 Адресация частей пакета

6.3.1 Общие положения

Настоящий документ предоставляет схему pack как способ использовать IRI (RFC 3987) для ссылок на ресурсы частей пакета внутри пакета.

Схемы представлены в IRI префиксом перед двоеточием. Хорошо известный пример — «http».

ПРИМЕР Пример IRI в схеме pack:

«pack://http%3c,,www.openxmlformats.org,my.container/a/b/foo.xml»

Подстрока между двойной косой чертой и первой одиночной косой чертой представляет IRI в схеме http для пакета, преобразованный для возможности встраивания в IRI в схеме pack.

Ссылки извне пакета являются абсолютными IRI схемы pack, тогда как ссылки изнутри являются относительными IRI, разрешаемыми в абсолютные IRI этой схемы.

6.3.2 Схема pack

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

Синтаксис IRI pack определён в EBNF (см. RFC 5234) следующим образом:

pack_IRI  = "pack://" iauthority [ "/" | ipath ]  
iauthority = *( iunreserved | sub-delims | pct-encoded ) 
ipath = 1*( "/" isegment ) 
isegment = 1*( ipchar ) 
ipchar = <ipchar, see [RFC3987], Section 2.2> 

iunreserved = <iunreserved, see [RFC3987], Section 2.2> 
sub-delims = <sub-delims, see [RFC3986], Section 2.2> 
pct-encoded = <pct-encoded, see [RFC3986], Section 2.1> 

Компонент полномочий (iauthority) содержит встроенный IRI, указывающий на пакет. (Процедуру преобразования IRI пакета, позволяющую встроить его в IRI pack как компонент полномочий, см. в 6.3.4.) Компонент полномочий НЕ ДОЛЖЕН (SHALL NOT) ссылаться на пакет, встроенный в другой пакет.

ПРИМЕЧАНИЕ Определение компонента полномочий требует, чтобы символ двоеточия (:) экранировался как %3c. Однако в предложенной регистрации схемы pack по ошибке был использован неэкранированный символ двоеточия (:). Вследствие этой ошибки предварительная схема pack была зарегистрирована IANA как историческая схема. Схему pack можно просмотреть в реестре схем, поддерживаемом IANA (см. ссылку [8]).

Необязательный компонент пути (ipath) идентифицирует конкретную часть пакета внутри пакета. Если компонент пути отсутствует, ресурс, идентифицируемый IRI pack, представляет собой пакет в целом.

IRI pack может иметь компонент запроса (как указано в RFC 3986). Компонент запроса в IRI pack не используется при разрешении IRI в часть пакета.

IRI pack может иметь компонент фрагмента (как указано в RFC 3986). При наличии этот фрагмент применяется к любому ресурсу, который идентифицирует IRI pack.

ПРИМЕР 1 Использование IRI pack для идентификации части пакета

Следующий IRI идентифицирует часть пакета «/a/b/foo.xml» в ресурсе пакета «http://www.openxmlformats.org/my.container»:

«pack://http%3c,,www.openxmlformats.org,my.container/a/b/foo.xml»

ПРИМЕР 2 Эквивалентные IRI pack

Следующие IRI pack эквивалентны:

«pack://http%3c,,www.openxmlformats.org,my.container»
«pack://http%3c,,www.openxmlformats.org,my.container/»

ПРИМЕР 3 IRI pack с процентно закодированными символами

Следующий IRI идентифицирует часть пакета «/c/d/bar.xml» в пакете «http://myalias:pswr@www.my.com/containers.aspx?my.container»:

6.3.3 Разрешение IRI pack в ресурс

Для разрешения IRI pack в ресурс (либо пакет, либо часть пакета) ДОЛЖЕН (SHALL) использоваться следующий алгоритм:

a) Разобрать IRI pack на потенциальные три компонента: схему, полномочия, путь, а также любой идентификатор фрагмента.

b) В компоненте authority замените все запятые («,» ) косыми чертами («/»).

c) Выполните процентное декодирование ASCII-символов в полученном компоненте authority.

d) Полученный компонент authority ДОЛЖЕН (SHALL) быть допустимым IRI для пакета в целом. В противном случае IRI pack является недопустимым.

e) Если компонент пути пуст, IRI pack разрешается в пакет в целом и процесс разрешения завершён.

f) Непустой компонент пути ДОЛЖЕН (SHALL) быть допустимым именем части пакета. В противном случае IRI pack является недопустимым.

g) IRI pack разрешается в часть пакета с этим именем в пакете, идентифицированном компонентом authority.

ПРИМЕР. Разрешение IRI pack в ресурс

Дан IRI pack:

"pack://http%3c,,www.my.com,packages.aspx%3fmy.package/a/b/foo.xml"

Компоненты:

"<authority>= http%3c,,www.my.com,packages.aspx%3fmy.package"
"<path>= /a/b/foo.xml"

преобразуются в IRI пакета:

"http://www.my.com/packages.aspx?my.package"

и путь:

"/a/b/foo.xml"

Следовательно, этот IRI ссылается на часть пакета с именем "/a/b/foo.xml" в пакете со следующим IRI:

"http://www.my.com/packages.aspx?my.package".

6.3.4 Формирование IRI pack

Следующий алгоритм ДОЛЖЕН (SHALL) использоваться для формирования IRI pack из абсолютного IRI целого пакета и имени части пакета:

a) Удалите идентификатор фрагмента из абсолютного IRI пакета, если он присутствует.

b) Выполните процентное кодирование всех знаков процента («%»), вопросительных знаков («?»), знаков «at» («@»), двоеточий («:») и запятых («,» ) в IRI пакета.

c) Замените все косые черты («/») запятыми («,» ) в полученной строке.

d) Добавьте полученную строку к строке "pack://".

e) Добавьте косую черту («/») к полученной строке. Сформированная строка представляет IRI pack с пустым компонентом пути.

f) Используя эту сформированную строку как базовый IRI, а имя части пакета как относительную ссылку, примените правила, определённые в RFC 3986, для разрешения относительных ссылок относительно базового IRI.

ПРИМЕР. Формирование IRI pack

Дан IRI пакета:

"http://www.my.com/packages.aspx?my.package"

и имя части пакета:

"/a/foo.xml"

IRI pack имеет вид:

"pack://http%3c,,www.my.com,packages.aspx%3fmy.package/a/foo.xml"

6.3.5 Эквивалентность

Два IRI pack ДОЛЖНЫ (SHALL) рассматриваться как эквивалентные, если:

a) компоненты схемы побайтно идентичны после преобразования обоих в нижний регистр; и

b) IRI, декодированные, как описано в 6.3.3, из компонентов authority, эквивалентны (правила эквивалентности определяются схемой), как указано в RFC 3986; и

c) компоненты пути являются эквивалентными именами частей пакета, как указано в 6.2.2.

ПРИМЕЧАНИЕ. В некоторых сценариях, таких как кэширование или запись частей пакета в пакет, необходимо определить, эквивалентны ли два IRI pack, не разрешая их.

6.4 Разрешение относительных ссылок

6.4.1 Общие положения

Относительные ссылки в частях пакета ДОЛЖНЫ (SHALL) разрешаться, как указано в RFC 3986 (5 «Разрешение ссылок»), с расширениями RFC 3987 (6.5 «Относительные ссылки IRI»).

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

6.4.2 Базовые IRI

В этом подпункте определена процедура определения базовых IRI для разрешения относительных ссылок внутри частей пакета в пакетах.

ПРИМЕЧАНИЕ. RFC 3986, 5.1 «Установление базового URI», устанавливает четыре общих метода, в порядке приоритета, для определения базовых IRI при разрешении относительных ссылок. Процедура этого подпункта задаёт метод, специфичный для OPC, соответствующий второму общему методу (RFC 3986, 5.1.2 «Базовый URI от инкапсулирующей сущности»).

Базовый IRI зависит от того, где эта ссылка находится в пакете. Этот подпункт охватывает случай, когда относительная ссылка находится в части пакета, не являющейся частью Relationships. В 6.5.2 рассматривается случай, когда относительная ссылка находится в части Relationships.

Базовым IRI ДОЛЖЕН (SHALL) быть IRI pack, сформированный из IRI пакета и имени части пакета, в которой находится относительная ссылка.

ПРИМЕР

Рассмотрим часть пакета /a/b/foo.xml в пакете, расположенном по адресу

"http://www.mysite.com/my.package"

Базовый IRI имеет вид

"pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml"

6.4.3 Примеры

6.4.3.1 Общие положения

В этом подпункте приведены примеры разрешения относительных ссылок. Для каждого примера в этом подпункте рассматриваются три случая.

Случай 1: базовый IRI является IRI pack, "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml", который сформирован из абсолютного IRI пакета и имени части пакета.

Случай 2: базовый IRI является IRI pack, "pack://http%3c,,www.mysite.com,my.package/", который создан из абсолютного IRI пакета.

Случай 3: базовым IRI является абсолютный IRI пакета, "http://www.mysite.com/my.package".

6.4.3.2 Начальная косая черта: "/b/bar.xml"

Случай 1: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml".

Поскольку эта относительная ссылка начинается с символа косой черты, компонент пути базового IRI ("/a/b/foo.xml") игнорируется алгоритмом из 5.2.2 RFC 3986. Схема и authority результирующего IRI совпадают со схемой и authority базового IRI pack. Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/b/bar.xml"

Случай 2: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/".

Аналогично, компонент пути базового IRI ("/") игнорируется. Остальное совпадает.

Случай 3: базовый IRI имеет вид "http://www.mysite.com/my.package".

Аналогично, компонент пути базового IRI ("/my.package") игнорируется. Таким образом, результирующий IRI имеет вид: "http://www.mysite.com/b/bar.xml"

6.4.3.3 Без начальной косой черты: "bar.xml"

Случай 1: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml".

Поскольку эта относительная ссылка не начинается с символа косой черты, компонент пути базового IRI ("/a/b/foo.xml") и компонент пути относительной ссылки ("bar.xml") объединяются. Процедура объединения из 5.2.3 RFC 3986 сначала удаляет "foo.xml" из компонента пути базового IRI и выдаёт "/a/b/bar.xml". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/a/b/bar.xml"

Случай 2: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/".

Аналогично, компонент пути базового IRI ("/") и компонент пути относительной ссылки ("bar.xml") объединяются. Процедура объединения выдаёт "/bar.xml". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/bar.xml"

Случай 3: базовый IRI имеет вид "http://www.mysite.com/my.package".

Аналогично, компонент пути базового IRI ("/my.package") и компонент пути относительной ссылки ("bar.xml") объединяются. Процедура объединения сначала удаляет "my.package" из компонента пути базового IRI и выдаёт "/bar.xml". Таким образом, результирующий IRI имеет вид: "http://www.mysite.com/bar.xml"

6.4.3.4 Сегмент с точкой: "./bar.xml"

Случай 1: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml".

Как и в 6.4.3.3, процедура объединения удаляет "foo.xml" из компонента пути базового IRI и выдаёт "/a/b/./bar.xml". Но процедура remove_dot_segments из 5.2.4 RFC 3986 удаляет "./" и выдаёт "/a/b/bar.xml". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/a/b/bar.xml"

Случай 2: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/".

Процедура объединения выдаёт "/./bar.xml", но процедура remove_dot_segments удаляет "./" и выдаёт "/bar.xml". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/bar.xml"

Случай 3: базовый IRI имеет вид "http://www.mysite.com/my.package".

Аналогично, компонент пути базового IRI ("/my.package") и компонент пути относительной ссылки ("./bar.xml") объединяются. Процедура объединения сначала удаляет "my.package" из компонента пути базового IRI и выдаёт "/./bar.xml". Но процедура remove_dot_segments удаляет "./" и выдаёт "/bar.xml". Таким образом, результирующий IRI имеет вид: "http://www.mysite.com/bar.xml"

6.4.3.5 Сегмент с точкой: "../bar.xml"

Случай 1: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml".

Процедура объединения выдаёт "/a/b/../bar.xml", но процедура remove_dot_segments удаляет "b/..". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/a/bar.xml"

Случай 2: базовый IRI имеет вид "pack://http%3c,,www.mysite.com,my.package/".

Процедура объединения выдаёт "/../bar.xml", но процедура remove_dot_segments заменяет "/../" на "/". Таким образом, результирующий IRI имеет вид: "pack://http%3c,,www.mysite.com,my.package/bar.xml"

Случай 3: базовый IRI имеет вид "http://www.mysite.com/my.package".

Аналогично, компонент пути базового IRI ("/my.package") и компонент пути относительной ссылки ("../bar.xml") объединяются. Процедура объединения сначала удаляет "my.package" из компонента пути базового IRI и выдаёт "/../bar.xml". Процедура remove_dot_segments заменяет "/../" на "/" и выдаёт "/bar.xml". Результирующий IRI имеет вид: "http://www.mysite.com/bar.xml"

6.5 Связи

6.5.1 Общие положения

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

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

Существуют два режима цели для разрешения относительных ссылок на цели. Разрешение во внутреннем режиме цели предоставляет части пакета, а во внешнем режиме цели — внешние ресурсы.

Связи имеют идентификаторы связей. Эти идентификаторы позволяют отличать связи друг от друга. Идентификатор также может использоваться для связывания цели связи с определённой точкой в исходной части пакета (например, для представления гиперссылки) посредством встраивания идентификатора связи в этой точке.

Связь имеет тип связи.

Связи представляются в XML в частях Relationships. Если сам пакет или какая-либо часть пакета является источником одной или нескольких связей, имеется связанная с ним часть Relationships. Эта часть содержит перечень связей для источника. Пространство имён Relationships и типы связей для частей пакета, определённых в настоящем документе, перечислены в приложении E.

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

6.5.2 Часть Relationships

6.5.2.1 Часть Relationships

Каждый набор связей, имеющих общий источник, представляется частью Relationships. Связей от части Relationships или к ней быть НЕ ДОЛЖНО (SHALL NOT).

Часть Relationships ДОЛЖНА (SHALL) быть либо частью Relationships пакета (6.5.2.2), либо частью Relationships части пакета (6.5.2.3).

6.5.2.2 Часть Relationships пакета

Часть Relationships пакета ДОЛЖНА (SHALL) быть частью Relationships, содержащей связи пакета и никакие другие связи.

Имя части Relationships пакета ДОЛЖНО (SHALL) быть /_rels/.rels.

Если в части Relationships пакета имеется относительная ссылка, базовый IRI зависит от режима цели связи. Если режим цели является внешним, базовым IRI ДОЛЖЕН (SHALL) быть абсолютный IRI пакета. Если режим цели является внутренним, базовым IRI ДОЛЖЕН (SHALL) быть IRI pack, созданный из абсолютного IRI пакета.

ПРИМЕР Рассмотрим часть Relationships пакета для пакета, расположенного по адресу http://www.mysite.com/my.package.

Если режим цели является внешним, базовый IRI: "http://www.mysite.com/my.package"

Если режим цели является внутренним, базовый IRI: "pack://http%3c,,www.mysite.com,my.package/"

6.5.2.3 Часть Relationships части пакета

Часть Relationships части пакета ДОЛЖНА (SHALL) быть частью Relationships, содержащей связи части пакета от одной и той же исходной части пакета и никакие другие связи.

Имя части Relationships части пакета ДОЛЖНО (SHALL) быть образовано из имени исходной части пакета добавлением .rels в конец последнего сегмента I18N и вставкой сегмента I18N «_rels» непосредственно перед последним сегментом I18N.

ПРИМЕР 1 Если имя исходной части пакета равно /foo, имя части Relationships части пакета равно /_rels/foo.rels. И наоборот, если имя части пакета равно /_rels/foo.rels, она является частью Relationships части пакета для исходной части пакета /foo. Если имя исходной части пакета равно /foo/bar.xml, имя части Relationships части пакета равно /foo/_rels/bar.xml.rels. И наоборот, если имя части пакета равно /foo/_rels/bar.xml.rels, она является частью Relationships части пакета для исходной части пакета /foo/bar.xml.

Если в части Relationships части пакета имеется относительная ссылка, базовый IRI зависит от режима цели связи. Если режим цели является внешним, базовым IRI ДОЛЖЕН (SHALL) быть абсолютный IRI пакета. Если режим цели является внутренним, базовым IRI ДОЛЖЕН (SHALL) быть IRI pack, созданный из абсолютного IRI пакета и имени исходной части пакета.

ПРИМЕР 2 Рассмотрим часть Relationships части пакета /a/b/_rels/foo.xml.rels в пакете, расположенном по адресу "http://www.mysite.com/my.package"

Если режим цели является внешним, базовый IRI: "http://www.mysite.com/my.package"

Если режим цели является внутренним, базовый IRI: "pack://http%3c,,www.mysite.com,my.package/a/b/foo.xml"

6.5.3 Разметка связей

6.5.3.1 Общие положения

Содержимое части Relationships ДОЛЖНО (SHALL) быть XML-документом. После удаления всех расширений процессором MCE, как указано в ECMA-376-3, часть Relationships ДОЛЖНА (SHALL) быть XML-документом, допустимым по схеме opc-relationships.xsd (C.5). Для этой обработки MCE конфигурация разметки ДОЛЖНА (SHALL) быть пустой, а конфигурация приложения ДОЛЖНА (SHALL) содержать только пространство имён Relationships.

Выходной документ, полученный в результате любой обработки MCE части Relationships, НЕ ДОЛЖЕН (SHALL NOT) содержать атрибут xml:base, как установлено XML Base.

6.5.3.2 Поддержка версионирования и расширяемости

Части Relationships МОГУТ (MAY) использовать механизмы версионирования и расширяемости, определённые в ECMA-376-3, для включения элементов и атрибутов, взятых из других пространств имён XML.

6.5.3.3 Элемент Relationships

Элемент Relationships является корневым элементом части Relationships. Он является контейнером для нуля или более элементов Relationship. Он не имеет атрибутов. Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_Relationships, определённый в схеме opc-relationships.xsd (C.5).

6.5.3.4 Элемент Relationship

Элемент Relationship ДОЛЖЕН (SHALL) представлять связь. Источником связи ДОЛЖЕН (SHALL) быть либо пакет, либо часть пакета, с которой ассоциирована часть Relationships, содержащая этот элемент Relationship.

Type="http://schemas.openxmlformats.org/package/2006/rela
tionships/digital-signature/signature" 

Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_Relationship, определённый в схеме opc-relationships.xsd (C.5).

6.5.4 Примеры

6.5.4.1 Часть Relationships, связанная со всем пакетом

Рассмотрим пакет, расположенный по адресу http://www.example.com/ex.opc. Предположим, что пакет содержит часть Relationships /_rels/.rels. Эта часть Relationships является частью Relationships пакета, которая связана со всем пакетом.

Также предположим, что содержимое этой части Relationships пакета представляет собой XML-документ, показанный ниже:

<Relationships  
   xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> 
   <Relationship  
      Target="a.xml"  
      Id="IDI1" 
      Type="http://example.com/relTypeInt1"/> 
   <Relationship  
      Target="a.xml" 
      TargetMode="External" 
      Id="IDE1" 
      Type="http://example.com/relTypeExt1"/>        
</Relationships> 

Два элемента Relationship в этой части Relationships пакета задают две связи. Источником каждой связи является пакет.

Первая связь:

• Режим цели — Internal (по умолчанию). Следовательно, базовый IRI для разрешения a.xml — это IRI pack (pack://http%3c,,www.example.com,ex.opc), созданный из IRI пакета (http://www.example.com/ex.opc).

• Результатом разрешения a.xml является pack://http%3c,,www.example.com,ex.opc/a.xml. Таким образом, целью этой связи является часть пакета "/a.xml" в данном пакете.
• Типом связи этой связи является http://example.com/relTypeInt1.
• Идентификатором этой связи является «IDI1».

Вторая связь:

• Режим цели — External. Следовательно, базовым IRI для разрешения a.xml является IRI (http://www.example.com/ex.opc) пакета.
• Таким образом, целью этой связи является ресурс по адресу http://www.example.com/a.xml.
• Типом связи этой связи является http://example.com/relTypeExt1.
• Идентификатором этой связи является «IDE1».

6.5.4.2 Часть Relationships, связанная с частью пакета

Рассмотрим пакет, расположенный по адресу http://www.example.com/ex.opc. Предположим, что пакет содержит часть Relationships /foo/_rels/test.xml.rels. Эта часть Relationships является частью Relationships части пакета, источником которой является часть пакета /foo/test.xml.

Также предположим, что содержимое этой части Relationships части пакета представляет собой XML-документ, показанный ниже:

<Relationships  
   xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> 
   <Relationship  
      Target="b.xml"  
      Id="IDI2" 
      Type="http://example.com/relTypeInt2"/> 
   <Relationship  
      Target="b.xml" 
      TargetMode="External" 
      Id="IDE2" 
      Type="http://example.com/relTypeExt2"/>        
</Relationships> 

Два элемента Relationship в этой части Relationships части пакета задают две связи. Источником каждой связи является часть пакета /foo/test.xml.

Первая связь:

• Режим первой связи — Internal (по умолчанию). Следовательно, базовый IRI (pack://http%3c,,www.example.com,ex.opc/foo/test.xml) является IRI pack, созданным из IRI (http://www.example.com/ex.opc) пакета и имени части пакета /foo/test.xml.
• Результатом разрешения b.xml является pack://http%3c,,www.example.com,ex.opc/foo/b.xml. Таким образом, целью этой связи является часть пакета /foo/b.xml в данном пакете.

• Типом связи этой связи является http://example.com/relTypeInt2.
• Идентификатором этой связи является «IDI2».

Вторая связь:

• Режим второй связи — External. Следовательно, базовым IRI является IRI (http://www.example.com/ex.opc) пакета.
• Таким образом, целью этой связи является ресурс по адресу http://www.example.com/b.xml.
• Типом связи этой связи является http://example.com/relTypeExt2.
• Идентификатором этой связи является «IDE2».

6.5.4.3 Части Relationships, относящиеся к разметке цифровой подписи

Часть пакета Digital Signature Origin (10.4.2) является целью связи пакета, которая хранится в части Relationships пакета /_rels/.rels.

ПРИМЕР 1

Элемент Relationship, представляющий связь пакета с частью пакета Digital Signature Origin:

<Relationship Id="rId4"  
  Type="http://schemas.openxmlformats.org/package/2006/relationships/ 
  digital-signature/origin" 
  Target="_xmlsignatures/origin.sigs"/> 

Соединение от Digital Signature Origin к части пакета Digital Signature XML Signature представляется связью части пакета, которая хранится в части Relationships части пакета /_xmlsignatures/_rels/origin.sigs.rels.

ПРИМЕР 2

XML-документ, представляющий содержимое /_xmlsignatures/_rels/origin.sigs.rels:

<Relationships 
   xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> 
   <Relationship  
      Target="sig1.xml"  
      Id="rId1" 
      Type="http://schemas.openxmlformats.org/package/2006/relationships/ 
         digital-signature/signature"/>  
</Relationships> 

6.5.4.4 Связи, целью которых являются внешние ресурсы

Связи могут иметь в качестве целей ресурсы вне пакета, расположенные по абсолютному адресу, и ресурсы, расположенные относительно текущего местоположения пакета. Следующая часть Relationships задаёт связи, соединяющие пакет или часть пакета с pic1.jpg по внешнему абсолютному адресу и с my_house.jpg по внешнему адресу относительно местоположения пакета:

<Relationships  
   xmlns="http://schemas.openxmlformats.org/package/2006/relationships" 
   <Relationship 
      TargetMode="External" 
      Id="A9EFC627517BC" 
      Target="http://www.example.com/images/pic1.jpg" 
      Type="http://www.example.com/external-resource"/> 
   <Relationship    
      TargetMode="External" 
      Id="A5EFC797514BC" 
      Target="images/my_house.jpg" 
      Type="http://www.example.com/external-resource"/> 
</Relationships> 

6.5.4.5 Несколько связей с одной и той же целью

Следующая часть Relationships содержит две связи, каждая из которых использует уникальное значение Id. Связи имеют общую цель Target, но разные типы связей.

<Relationships  
   xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> 
   <Relationship  
      Target="Signature.xml"  
      Id="A5FFC797514BC" 
      Type="http://schemas.openxmlformats.org/package/2006/ 
         relationships/digital-signature/signature"/>  
   <Relationship  
      Target="Signature.xml"  
      Id="B5F32797CC4B7" 
      Type="http://www.example.com/internal-resource"/> 
</Relationships> 

7 Физическая модель пакета

7.1 Общие положения

В настоящем разделе вводится физическая модель пакета в терминах физического формата (например, формата ZIP) и отображения абстрактной модели пакета в этот физический формат. Дополнительное обсуждение вопросов проектирования физической модели пакета приведено в приложении F.

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

Пример физического пакета описан в H.3.

7.2 Руководящие принципы физического отображения

7.2.1 Использование возможностей физических форматов

Многие физические форматы имеют возможности, которые частично соответствуют компонентам абстрактной модели пакета. При отображении абстрактной модели пакета в физический формат СЛЕДУЕТ (SHOULD) использовать любые сходства возможностей абстрактной модели пакета и физического формата, применяя при этом уровни отображения для предоставления дополнительных возможностей, которые изначально отсутствуют в физическом формате. Например, некоторые физические форматы хранят части пакета как отдельные файлы в файловой системе; в этом случае целесообразно отображать многие имена частей пакета непосредственно в соответствующие имена физических файлов.

7.2.2 Отображаемые компоненты

Физическая модель пакета ОБЯЗАНА (REQUIRED) представлять пакеты, части пакета (включая части Relationships), имена частей пакета и типы носителя частей пакета, но НЕ ОБЯЗАНА (NOT REQUIRED) представлять подсказку роста.

7.2.3 Отображение типов носителей на части пакета

7.2.3.1 Общие положения

Физический формат может иметь встроенный механизм сопоставления типов носителей с частями пакета. Например, поле Content-Type в заголовке MIME-сущности сопоставляет тип носителя с этой MIME-сущностью. Для такого физического формата отображения из абстрактной модели пакета СЛЕДУЕТ (SHOULD) выполнять с использованием встроенного механизма.

Для всех остальных физических форматов пакет ДОЛЖЕН (SHALL) включать XML-поток, называемый в настоящем документе потоком Media Types. Поток Media Types НЕ ДОЛЖЕН (SHALL NOT) представлять часть пакета. Этот поток НЕ ДОЛЖЕН (SHALL NOT) быть адресуемым посредством URI. Однако он МОЖЕТ (MAY) быть перемежён в физическом пакете с использованием тех же механизмов, которые используются для перемежения частей пакета.

7.2.3.2 Разметка потока Media Types

7.2.3.2.1 Общие положения

Содержимое потока Media Types ДОЛЖНО (SHALL) быть XML-документом, действительным по схеме opc-contentTypes.xsd (C.2). Этот XML-документ ДОЛЖЕН (SHALL) иметь элемент верхнего уровня Types, а также один или несколько дочерних элементов Default и Override. Элементы Default ДОЛЖНЫ (SHALL) определять отображения по умолчанию расширений имён частей пакета на типы носителей. Элементы Override ДОЛЖНЫ (SHALL) задавать типы носителей для частей пакета, которые не охватываются отображениями по умолчанию либо не соответствуют им. Обратите внимание, что элементы Default могут использоваться для уменьшения числа элементов Override для части пакета.

Для всех частей пакета, кроме частей Relationships (6.5.2), поток Media Types ДОЛЖЕН (SHALL) задавать одно из следующего:

• Один соответствующий элемент Default, либо
• Один соответствующий элемент Override, либо
• Как соответствующий элемент Default, так и соответствующий элемент Override; в этом случае элемент Override имеет приоритет.

Для любого заданного расширения НЕ ДОЛЖНО (SHALL NOT) быть более одного элемента Default, а для любого заданного имени части пакета НЕ ДОЛЖНО (SHALL NOT) быть более одного элемента Override.

Порядок элементов Default и Override в потоке Media Types НЕ ДОЛЖЕН (SHALL NOT) быть значимым.

Поток Media Types МОЖЕТ (MAY) определять элементы Default, даже если их не использует ни одна часть пакета.

7.2.3.2.2 Поддержка версионирования и расширяемости

Поток Media Types НЕ ДОЛЖЕН (SHALL NOT) использовать механизмы версионирования и расширяемости, определённые в ECMA-376-3.

7.2.3.2.3 Элемент Types

Элемент Types ДОЛЖЕН (SHALL) быть корневым элементом XML-документа, содержащегося в потоке Media Types.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_Types, определённый в схеме opc-contentTypes.xsd (C.2).

7.2.3.2.4 Элемент Default

Элемент Default ДОЛЖЕН (SHALL) задавать отображения по умолчанию расширений имён частей пакета на типы носителей.

Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_Default, определённый в схеме opc-contentTypes.xsd (C.2).

7.2.3.2.5 Элемент Override

Элемент Override ДОЛЖЕН (SHALL) задавать тип носителя для части пакета, которая не охватывается отображениями по умолчанию либо не соответствует им.

Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_Override, определённый в схеме opc-contentTypes.xsd (C.2).

7.2.3.3 Пример разметки потока Media Types

ПРИМЕР Разметка потока Media Types

<Types  
   xmlns="http://schemas.openxmlformats.org/package/2006/content-types"> 
   <Default Extension="txt" ContentType="text/plain" /> 
   <Default Extension="jpeg" ContentType="image/jpeg" /> 
   <Default Extension="picture" ContentType="image/gif" /> 
   <Override PartName="/a/b/sample4.picture" ContentType="image/jpeg" /> 
</Types> 

Элемент Types является контейнером для типов носителей, используемых в пакете.

Ниже приведён примерный перечень частей пакета и соответствующих им типов носителей, определённых приведённой выше разметкой потока Media Types.

7.2.3.4 Задание типа носителя части пакета в потоке Media Types

При добавлении новой части пакета в пакет реализатор пакета ДОЛЖЕН (SHALL) обеспечить, чтобы тип носителя этой части пакета был задан в потоке Media Types. Для этого реализатор пакета ДОЛЖЕН (SHALL) выполнить следующие действия:

1. a) Получить расширение из имени части пакета, взяв подстроку справа от крайнего правого вхождения символа точки («.») в крайнем правом сегменте.
2. b) Если имя части пакета не имеет расширения, в поток Media Types ДОЛЖЕН (SHALL) быть добавлен соответствующий элемент Override.
3. c) Сравнить полученное расширение со значениями, указанными для атрибутов Extension элементов Default в потоке Media Types. Сравнение ДОЛЖНО (SHALL) быть ASCII-независимым от регистра сопоставлением.
4. d) Если существует элемент Default с соответствующим атрибутом Extension, то тип носителя новой части пакета ДОЛЖЕН (SHALL) быть сравнен со значением атрибута ContentType. Сравнение ДОЛЖНО (SHALL) быть независимым от регистра и учитывать каждый символ независимо от его роли в грамматике типа содержимого RFC 7231.
   1. Если типы носителей совпадают, дальнейшие действия не требуются.
   2. Если типы носителей не совпадают, в поток Media Types ДОЛЖЕН (SHALL) быть добавлен новый элемент Override.
5. e) Если не существует элемента Default с соответствующим атрибутом Extension, в поток Media Types ДОЛЖЕН (SHALL) быть добавлен новый элемент Default или Override.

7.2.3.5 Определение типа носителя части пакета по потоку Media Types

Чтобы получить тип носителя части пакета, реализатор пакета ДОЛЖЕН (SHALL) выполнить следующие действия:

1. a) Сравнить имя части пакета со значениями, указанными для атрибута PartName элементов Override. Сравнение ДОЛЖНО (SHALL) быть ASCII-независимым от регистра сопоставлением.
2. b) Если существует элемент Override с соответствующим атрибутом PartName, вернуть значение его атрибута ContentType. Дальнейшие действия не требуются.
3. c) Если не существует элемента Override с соответствующим атрибутом PartName, то:
   1. Получить расширение из имени части пакета, взяв подстроку справа от крайнего правого вхождения символа точки («.») в крайнем правом сегменте.
   2. Проверить элементы Default потока Media Types, сопоставляя расширение со значением атрибута Extension. Сравнение ДОЛЖНО (SHALL) быть ASCII-независимым от регистра сопоставлением.
4. d) Если существует элемент Default с соответствующим атрибутом Extension, вернуть значение его атрибута ContentType. Дальнейшие действия не требуются.

ПРИМЕЧАНИЕ Для соответствующего требованиям пакета либо элемент Override находится на шаге b), либо элемент Default находится на шаге c).

7.2.4 Перемежение

При отображении абстрактного пакета в физический пакет поток данных части пакета или поток Media Types МОЖЕТ (MAY) быть разбит на фрагменты. Каждый фрагмент ДОЛЖЕН (SHALL) представлять поток данных, который может быть пустым. Позднее фрагменты могут быть объединены, образуя исходный поток, на основе имён фрагментов, как установлено в 7.2.5.2.

Физический пакет МОЖЕТ (MAY) содержать как перемежаемые, так и неперемежаемые части пакета. Перемежаемые части пакета ДОЛЖНЫ (SHALL) быть частями пакета, разбитыми на фрагменты. Неперемежаемые части пакета ДОЛЖНЫ (SHALL) быть частями пакета, не разбитыми на фрагменты.

Фрагменты ДОЛЖНЫ (SHALL) существовать только в физическом пакете и НЕ ДОЛЖНЫ (SHALL NOT) быть адресуемыми в абстрактной модели пакета. Фрагменты ДОЛЖНЫ (SHALL) располагаться в естественном порядке их номеров и МОГУТ (MAY) быть перемежены с фрагментами других частей пакета либо с неперемежаемыми частями пакета.

Благодаря обеспечиваемым преимуществам производительности реализаторам пакетов СЛЕДУЕТ (SHOULD) поддерживать перемежение, однако они НЕ ОБЯЗАНЫ (NOT REQUIRED) это делать.

Дополнительное обсуждение преимуществ перемежения для производительности приведено в F.3.

7.2.5 Отображение имён частей пакета на имена элементов физического пакета

7.2.5.1 Общие положения

Отображение абстрактного пакета в физический пакет ДОЛЖНО (SHALL) использовать логические элементы в качестве промежуточных объектов, чтобы допустить перемежение (7.2.4). Если часть пакета или поток Media Types перемежается, каждый созданный из него фрагмент ДОЛЖЕН (SHALL) быть логическим элементом; в противном случае часть пакета или поток Media Types ДОЛЖЕН (SHALL) быть логическим элементом. См. рисунок 1.

7.2.5.2 Имена логических элементов

Имена логических элементов ДОЛЖНЫ (SHALL) быть строками Unicode. Поддержка символов, не входящих в ASCII, не требуется.

Если логический элемент является фрагментом, его имя ДОЛЖНО (SHALL) иметь суффиксы следующего синтаксиса:

SuffixName = "/" "[" PieceNumber "]" [".last"] ".piece" 
PieceNumber = "0" | NonZeroDigit [1*Digit] 
Digit  = "0" | NonZeroDigit 
NonZeroDigit = "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"  

Префикс имени логического элемента является результатом удаления суффикса, если таковой имеется, из имени логического элемента.

Эквивалентность префиксов и суффиксов ДОЛЖНА (SHALL) определяться ASCII-независимым от регистра сопоставлением. Логические имена ДОЛЖНЫ (SHALL) быть эквивалентными, если их префиксы и суффиксы эквивалентны. Физический пакет НЕ ДОЛЖЕН (SHALL NOT) содержать эквивалентные имена логических элементов.

Имена логических элементов, использующие суффиксные имена, ДОЛЖНЫ (SHALL) образовывать полную последовательность тогда и только тогда, когда:

1. a) имена префиксов всех имён логических элементов в последовательности эквивалентны; и
2. b) суффиксные имена последовательности начинаются с «/[0].piece» и заканчиваются «/[n].last.piece», а также включают фрагмент для каждого номера фрагмента от 0 до n без пропусков, когда номера фрагментов интерпретируются как десятичные целые значения.

7.2.5.3 Отображение имён частей пакета на имена логических элементов

Имена неперемежаемых частей пакета ДОЛЖНЫ (SHALL) отображаться на имена логических элементов, имеющие эквивалентный префикс и не имеющие суффикса.

Имена перемежаемых частей пакета ДОЛЖНЫ (SHALL) отображаться на полную последовательность имён логических элементов с эквивалентным префиксом.

7.2.5.4 Отображение имён логических элементов и имён элементов физического пакета

Отображение имён логических элементов и имён элементов физического пакета ДОЛЖНО (SHALL) быть специфичным для конкретного физического пакета.

7.2.5.5 Отображение имён логических элементов на имена частей пакета

Имя логического элемента без суффикса ДОЛЖНО (SHALL) отображаться на имя части пакета с эквивалентным префиксом при условии, что имя префикса соответствует синтаксису имени части пакета.

Полная последовательность имён логических элементов ДОЛЖНА (SHALL) отображаться на имя части пакета, равное префиксу имени логического элемента, имеющего суффикс «/[0].piece», при условии, что имя префикса соответствует синтаксису имени части пакета.

Физический пакет МОЖЕТ (MAY) содержать имена логических элементов и полные последовательности имён логических элементов, которые не могут быть отображены на имя части пакета, поскольку имя логического элемента не соответствует грамматике именования частей пакета. Такие логические элементы или полные последовательности логических элементов НЕ ДОЛЖНЫ (SHALL NOT) отображаться на части пакета.

ПРИМЕР Имя логического элемента «/[trash]/0000.dat» не может быть отображено на элемент части пакета. Следовательно, этот логический элемент не представляет часть пакета.

7.3 Отображение в ZIP-файл

7.3.1 Общие положения

Настоящий документ определяет отображение для формата ZIP-файла.

ZIP-файл, представляющий физический пакет, ДОЛЖЕН (SHALL) удовлетворять требованиям приложения B и СЛЕДУЕТ (SHOULD) рекомендациям приложения B.

Элементы физических пакетов ZIP-файлов ДОЛЖНЫ (SHALL) быть элементами ZIP. Следует отметить, что, когда пользователи распаковывают ZIP-пакет, они видят набор файлов и папок, отражающий части пакета и их иерархическую структуру именования.

В таблице 1 показаны различные компоненты абстрактной модели пакета и соответствующее им физическое представление в ZIP-файле.

7.3.2 Отображение данных частей пакета

Каждая неперемежаемая часть пакета ДОЛЖНА (SHALL) быть представлена одним элементом ZIP. Каждый фрагмент перемежаемой части пакета, как описано в 7.2.4, ДОЛЖЕН (SHALL) быть представлен одним элементом ZIP.

7.3.3 Имена элементов ZIP

Имена элементов ZIP ДОЛЖНЫ (SHALL) соответствовать ZIP Appnote. При отображении абстрактного пакета в ZIP-файл ДОЛЖНЫ (SHALL) использоваться только имена элементов ZIP в ASCII. Имена элементов ZIP ДОЛЖНЫ (SHALL) быть уникальными в пределах данного ZIP-файла.

ПРИМЕР. Следующие имена элементов ZIP в ZIP-файле отображаются на фрагменты частей пакета и целые части пакета:

"spine.xml/[0].piece" 
"pages/page0.xml" 
"spine.xml/[1].piece" 
"pages/page1.xml" 
"spine.xml/[2].last.piece" 
"pages/page2.xml" 

7.3.4 Отображение имён логических элементов на имена элементов ZIP

Для каждого логического элемента процесс отображения имён логических элементов на имена элементов ZIP ДОЛЖЕН (SHALL) включать следующие шаги в указанном порядке:

1. a) Удалить начальную косую черту («/») из имени логического элемента или, в случае перемежаемых частей пакета, из каждого имени логического элемента в полной последовательности.
2. b) Выполнить процентное кодирование каждого символа, не относящегося к ASCII.

7.3.5 Отображение имён элементов ZIP на имена логических элементов

Имена всех элементов ZIP ДОЛЖНЫ (SHALL) отображаться на имена логических элементов, за исключением элементов, которые не представляют файлов.

ПРИМЕЧАНИЕ. Для некоторых файловых систем ZIP Appnote содержит дополнительные сведения об элементах ZIP, распознаваемых как файлы.

Для каждого элемента ZIP процесс отображения имён элементов ZIP на имена логических элементов ДОЛЖЕН (SHALL) включать следующие шаги в указанном порядке:

1. a) Выполнить обратное процентное декодирование каждого символа, не относящегося к ASCII.
2. b) Добавить косую черту («/»).

7.3.6 Ограничения ZIP-пакетов

Настоящий документ требует, чтобы заголовок файла в структуре центрального каталога ZIP-файла НЕ ДОЛЖЕН (SHALL NOT) превышать 65 535 байтов (см. «F. Central directory structure» в ZIP Appnote). Каждый заголовок файла содержит имя элемента ZIP, поле Extra (включая байты, представляющие подсказку роста, как указано в 6.2.4), File Comment и ещё 42 байта, представляющие различные поля.

Реализаторам пакетов СЛЕДУЕТ (SHOULD) ограничивать именование частей пакета с учётом ограничений файловой системы при именовании частей пакета, предназначенных для хранения в качестве элементов ZIP.

ПРИМЕР. Примеры этих ограничений:

• В файловых системах MS Windows® звёздочка («*») не поддерживается, поэтому части пакета с именами, содержащими этот символ, не распаковываются успешно.
• В файловых системах MS Windows® многие программы могут обрабатывать только имена файлов длиной менее 256 символов, включая полный путь; после распаковки частей пакета они не могут обрабатывать части пакета с более длинными именами.

ZIP-пакеты НЕ ДОЛЖНЫ (SHALL NOT) включать шифрование, описанное в ZIP Appnote.

ZIP-пакеты НЕ ДОЛЖНЫ (SHALL NOT) использовать алгоритмы сжатия, кроме DEFLATE, как описано в ZIP Appnote.

7.3.7 Отображение потока Media Types

В ZIP-файлах поток Media Types ДОЛЖЕН (SHALL) храниться в элементе с именем "[Content_Types].xml" или, в случае перемежаемого упорядочения, в полной последовательности элементов ZIP "[Content_Types].xml/[0].piece", "[Content_Types].xml/[1].piece", … и "[Content_Types].xml/[n].last.piece".

ПРИМЕЧАНИЕ. Символы квадратных скобок «[» и «]» выбраны для имени потока Media Types специально потому, что эти символы нарушают грамматику именования частей пакета, тем самым усиливая требование о том, что имена элементов ZIP, сформированные из потока Media Types, всегда отличимы от имён, сформированных из имён частей пакета.

7.3.8 Отображение подсказки роста

Дополнительное пространство, предлагаемое подсказкой роста, хранится в поле Extra, как определено в ZIP Appnote. Если подсказка роста используется для перемежаемой части пакета, заполнение хранится в поле Extra элемента ZIP, представляющего первый фрагмент части пакета.

Формат поля Extra элемента ZIP при его использовании для подсказок роста приведён в таблице 2.

8 Основные свойства

8.1 Общие положения

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

8.2 Часть основных свойств

Пакет ДОЛЖЕН (SHALL) содержать не более одной части основных свойств.

На часть основных свойств в составе пакета ДОЛЖНА (SHALL) ссылаться связь основных свойств от пакета, как указано в приложении E. Пакет ДОЛЖЕН (SHALL) содержать не более одной связи основных свойств.

Типом носителя части основных свойств ДОЛЖЕН (SHALL) быть тип носителя части основных свойств, определённый в приложении E.

8.3 Разметка основных свойств

8.3.1 Общие положения

Содержимое части основных свойств ДОЛЖНО (SHALL) быть XML-документом, действительным относительно схемы opc-coreProperties.xsd (C.3).

Если не указано иное, элементы, представляющие часть основных свойств, ДОЛЖНЫ (SHALL) относиться к пространству имён, определённому в приложении E.

ПРИМЕР

Ниже приведён пример части основных свойств.

<coreProperties  
   xmlns="http://schemas.openxmlformats.org/package/2006/metadata/ 
      core-properties" 
   xmlns:dcterms="http://purl.org/dc/terms/"  
   xmlns:dc="http://purl.org/dc/elements/1.1/"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
   <dc:creator>Alan Shen</dc:creator> 
   <dcterms:created xsi:type="dcterms:W3CDTF"> 
      2005-06-12 
   </dcterms:created> 
 
   <dc:title>OPC Core Properties</dc:title> 

   <dc:description>Spec defines the schema for OPC Core Properties and 
their location within the package</dc:description> 
   <dc:language>eng</dc:language> 
   <version>1.0</version> 
   <lastModifiedBy>Alan Shen</lastModifiedBy> 
   <dcterms:modified xsi:type="dcterms:W3CDTF">2005-11-
23</dcterms:modified> 
   <contentStatus>Reviewed</contentStatus> 
   <category>Specification</category> 
</coreProperties> 

В этом примере dc:creator, dcterms:created, dc:title, dc:description, dc:language, version, lastModifiedBy, dcterms:modified, contentStatus и category являются элементами основных свойств.

8.3.2 Поддержка управления версиями и расширяемости

Часть основных свойств НЕ ДОЛЖНА (SHALL NOT) содержать элементы или атрибуты пространства имён совместимости разметки, определённого в ECMA-376-3.

ПРИМЕЧАНИЕ Возможности управления версиями и расширяемости реализуются путём создания новой части и использования связи с новым типом, указывающей от части основных свойств на новую часть. Настоящий документ не устанавливает требований или руководств для новых частей либо типов связей, используемых для расширения основных свойств. Такое руководство содержится в ISO/IEC TR 30114-1 (см. ссылку [4]).

8.3.3 Элемент coreProperties

Элемент coreProperties является корневым элементом части основных свойств.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Дочерними элементами этого элемента ДОЛЖНЫ (SHALL) быть элементы основных свойств, определённые в 8.3.4.

Содержимое этого элемента определено комплексным типом CT_CoreProperties, который определён в схеме opc-coreProperties.xsd (C.3).

8.3.4 Элементы основных свойств

8.3.4.1 Общие положения

Элементами основных свойств ДОЛЖНЫ (SHALL) быть элементы, представляющие основные свойства. Элементы основных свойств не повторяются. Они могут быть пустыми или отсутствовать.

8.3.4.2 Элементы основных свойств, определённые ISO 15836-1

Настоящий документ допускает элементы creator, description, identifier, language, subject и title в качестве элементов основных свойств. Если какой-либо из этих элементов включён, он ДОЛЖЕН (SHALL) соответствовать ISO 15836-1.

ПРИМЕЧАНИЕ Эти элементы принадлежат пространству имён «http://purl.org/dc/elements/1.1/».

Эти элементы НЕ ДОЛЖНЫ (SHALL NOT) иметь дочерних элементов и НЕ ДОЛЖНЫ (SHALL NOT) иметь атрибут xsi:type или атрибут xml:lang.

ПРИМЕР

Пример в 8.3.1 содержит четыре элемента из ISO 15836-1.

<dc:creator>Alan Shen</dc:creator> 
<dc:title>OPC Core Properties</dc:title> 
<dc:description>Spec defines the schema for OPC Core Properties and their 
location within the package</dc:description> 
<dc:language>eng</dc:language> 

8.3.4.3 Элементы основных свойств, определённые ISO 15836-2

Настоящий документ допускает элементы created и modified в качестве элементов основных свойств. Если включён один или оба этих элемента, они ДОЛЖНЫ (SHALL) соответствовать ISO 15836-2.

ПРИМЕЧАНИЕ Эти элементы принадлежат пространству имён «http://purl.org/dc/terms/».

Настоящий документ вводит дополнительные требования. Эти элементы НЕ ДОЛЖНЫ (SHALL NOT) иметь дочерних элементов и НЕ ДОЛЖНЫ (SHALL NOT) иметь атрибут xml:lang. Эти элементы ДОЛЖНЫ (SHALL) иметь атрибут xsi:type, значение которого равно "dcterms:W3CDTF" (см. ссылку [2]), а dcterms ДОЛЖЕН (SHALL) быть объявлен как префикс пространства имён Dublin Core "http://purl.org/dc/terms/".

ПРИМЕР

Пример в 8.3.1 содержит два элемента из DCMI Metadata Terms.

<dcterms:created xsi:type="dcterms:W3CDTF">2005-06-12</dcterms:created> 
<dcterms:modified xsi:type="dcterms:W3CDTF">2005-11-23</dcterms:modified> 

8.3.4.4 Элементы основных свойств, определённые в настоящем документе

8.3.4.4.1 Элемент category

Элемент category задаёт категорию содержимого пакета.

Этот элемент может иметь такие значения, как «Resume», «Letter», «Financial Forecast», «Proposal» и «Technical Presentation». Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:string.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР

Элемент category приведён в примере в 8.3.1.

8.3.4.4.2 Элемент contentStatus

Элемент contentStatus задаёт статус содержимого пакета.

Этот элемент может иметь такие значения, как «Draft», «Reviewed» и «Final». Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:string.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР

Пример в 8.3.1 содержит <contentStatus>Reviewed</contentStatus>

8.3.4.4.3 Элемент keywords

Элемент keywords задаёт ключевые слова для содержимого пакета.

Элемент keywords ДОЛЖЕН (SHALL) допускать необязательный атрибут xml:lang, определённый в XML 1.0. Элемент keywords имеет смешанную модель содержимого, так что каждое ключевое слово может быть по отдельности заключено в элемент value, имеющий атрибут xml:lang.

ПРИМЕР Следующий экземпляр элемента keywords содержит ключевые слова на английском (Канада), английском (США) и французском (Франция):

<keywords xml:lang="en-US"> 
  color  
  <value xml:lang="en-CA">colour</value> 
  <value xml:lang="fr-FR">couleur</value> 
</keywords> 

Определение модели содержимого этого элемента в W3C XML Schema приведено в комплексном типе CT_Keywords, который определён в схеме opc-coreProperties.xsd (C.3).

8.3.4.4.4 Элемент value

Элемент value задаёт ключевое слово для содержимого пакета.

Элемент value ДОЛЖЕН (SHALL) допускать необязательный атрибут xml:lang, определённый спецификацией XML 1.0.

Определением модели содержимого этого элемента в W3C XML Schema является комплексный тип CT_Keyword, определённый в схеме opc-coreProperties.xsd (C.3).

8.3.4.4.5 Элемент lastModifiedBy

Элемент lastModifiedBy задаёт, кто изменил содержимое пакета.

ПРИМЕР 1 Имя, адрес электронной почты или идентификатор работника.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:string.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР 2 Пример в 8.3.1 содержит <lastModifiedBy>Alan Shen</lastModifiedBy>

8.3.4.4.6 Элемент lastPrinted

Элемент lastPrinted задаёт, когда содержимое пакета было напечатано в последний раз.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:dateTime.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР 1 Пример в 8.3.1 содержит <lastPrinted>2017-01-01</lastPrinted>

ПРИМЕР 2 <lastPrinted>2017-04-17T14:20:10+09:00</lastPrinted>

8.3.4.4.7 Элемент revision

Элемент revision задаёт номер редакции содержимого пакета.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:string.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР <revision>4</revision>

8.3.4.4.8 Элемент version

Элемент version задаёт версию содержимого пакета.

Этот элемент НЕ ДОЛЖЕН (SHALL) иметь атрибутов.

Содержимое этого элемента определено простым типом xsd:string.

Определение этого элемента в W3C XML Schema приведено в схеме opc-coreProperties.xsd (C.3).

ПРИМЕР <version>1.0</version>

9 Миниатюры

Части миниатюр ДОЛЖНЫ (SHALL) быть частями изображений, идентифицируемыми либо связью части пакета, либо связью пакета. Эта связь ДОЛЖНА (SHALL) иметь тип связи для частей миниатюр, определённый в приложении E.

ПРИМЕЧАНИЕ Части миниатюр могут использоваться, чтобы помогать конечным пользователям идентифицировать части пакета или пакет в целом.

10 Цифровые подписи

10.1 Общие положения

Пакет МОЖЕТ (MAY) содержать разметку, указывающую, что части пакета были подписаны. В настоящем разделе описывается, как OPC применяет Рекомендацию W3C «XML-Signature Syntax and Processing» при формировании этой разметки.

10.2 Обзор ограничений и расширений OPC для «XML-Signature Syntax and Processing»

Цифровые подписи представляются отдельными частями пакета OPC. Иными словами, цифровые подписи отделены от подписываемого содержимого.

Настоящий документ вводит разметку для указания времени создания подписи. Эта разметка содержится в элементе Object.

Настоящий документ вводит разметку (10.5.8.2) и алгоритм преобразования (10.6) для гибкого определения подписываемых связей.

Настоящий документ предписывает использование элемента Manifest в качестве дочернего элемента элемента Object для перечисления подписываемых частей пакета.

10.3 Выбор подписываемого содержимого

Предполагается наличие политики подписи, определяющей, какие части пакета и связи подписывать.

Настоящий раздел обеспечивает гибкость при определении подписываемого содержимого, тем самым позволяя изменять другое содержимое. Дополнительные сведения о том, как определять подписываемое содержимое, приведены в 10.5.6 и 10.5.8.2.

10.4 Части пакета цифровой подписи

10.4.1 Общие положения

Цифровые подписи в пакетах используют часть пакета Digital Signature Origin, части пакета Digital Signature XML Signature и части пакета Digital Signature Certificate. Типы связей и типы носителей, относящиеся к использованию цифровых подписей в пакетах, определены в приложении E. Следует отметить, что пример связи от части пакета Digital Signature Origin к части пакета Digital Signature XML Signature приведён в 6.5.4.3.

На рисунке 2 показан подписанный пакет с частями пакета подписи, подписанными частями пакета и частью пакета сертификата X.509. Пример части пакета Digital Signature Origin имеет связи с двумя частями пакета Digital Signature XML Signature, каждая из которых содержит подпись. Подписи относятся к подписанным частям пакета.

10.4.2 Часть пакета Digital Signature Origin

Часть пакета Digital Signature Origin является начальной точкой для навигации по подписям в пакете. В пакете НЕ ДОЛЖНО (SHALL NOT) существовать более одной части пакета Digital Signature Origin, и эта часть пакета ДОЛЖНА (SHALL) быть целью связи Digital Signature Origin, определённой в приложении E, от пакета. Эта часть пакета ДОЛЖНА (SHALL) существовать, если пакет содержит какие-либо части пакета Digital Signature XML Signature, а в противном случае ДОЛЖНА (SHALL) быть необязательной. Содержимое части пакета Digital Signature Origin ДОЛЖНО (SHALL) быть пустым.

10.4.3 Часть пакета Digital Signature XML Signature

Часть пакета Digital Signature XML Signature ДОЛЖНА (SHALL) содержать подпись, представленную разметкой цифровой подписи (см. 10.5). Каждая часть пакета Digital Signature XML Signature ДОЛЖНА (SHALL) быть целью связи Digital Signature, определённой в приложении E, от части пакета Digital Signature Origin. Пакет МОЖЕТ (MAY) содержать более одной части пакета Digital Signature XML Signature.

ПРИМЕЧАНИЕ Если будущие версии настоящего документа определят различные типы связей для пересмотренных частей пакета подписи, пакеты смогут содержать различную информацию о подписях для разных версий. Для проверки ссылок и проверки подписей можно будет выбрать соответствующие цифровые подписи XML.

10.4.4 Часть пакета Digital Signature Certificate

Содержимым части пакета Digital Signature Certificate ДОЛЖЕН (SHALL) быть цифровой сертификат, определённый в X.509.

Сертификат X.509, используемый для проверки подписи, может:

• содержаться в части пакета Digital Signature XML Signature;

• образовывать отдельную часть пакета Digital Signature Certificate; или
• храниться вне пакета.

Если сертификат представлен отдельной частью пакета в пакете, этот сертификат ДОЛЖЕН (SHALL) быть целью связи части пакета Digital Signature Certificate, определённой в приложении E, от соответствующей части пакета Digital Signature XML Signature. Часть пакета, содержащая сертификат, МОЖЕТ (MAY) быть подписана. Тип носителя части пакета Digital Signature Certificate и связь, нацеленная на неё от части пакета Digital Signature XML Signature, определены в приложении E. Часть пакета Digital Signature Certificate МОЖЕТ (MAY) использоваться для создания более одной подписи. Часть пакета Digital Signature Certificate СЛЕДУЕТ (SHOULD) сделать целью по меньшей мере одной связи Digital Signature Certificate от части пакета Digital Signature XML Signature.

10.5 Разметка цифровой подписи

10.5.1 Общие положения

Содержимое части пакета Digital Signature XML Signature ДОЛЖНО (SHALL) быть XML-документом. Применяются требования, определённые в 6.2.5.

Содержимое каждой части пакета Digital Signature XML Signature ДОЛЖНО (SHALL) быть XML-документом, действительным по схеме xmldsig-core-schema.xsd, как определено в Рекомендации W3C «XML-Signature Syntax and Processing», и opc-digSig.xsd (см. C.4). Алгоритмы ДОЛЖНЫ (SHALL) идентифицироваться URI, как показано в этой рекомендации W3C или RFC 6931.

Подразделы с 10.5.2 по 10.5.18 охватывают специфические для OPC ограничения и расширения «XML-Signature Syntax and Processing». Подразделы предусмотрены для элементов, определённых для специфического использования OPC, либо для которых OPC вводит ограничения. Элементы, определённые в «XML-Signature Syntax and Processing» (такие как X509Certificate), для которых ниже не предусмотрен подраздел, разрешены в пакетах OPC без ограничений.

Специфические для OPC элементы принадлежат пространству имён Digital Signatures (см. таблицу E.1). Их определения схемы доступны через C.4.

ПРИМЕЧАНИЕ Общий пример разметки цифровой подписи XML приведён в разделе 2 «XML-Signature Syntax and Processing». Полный пример специфической для OPC цифровой подписи приведён в 10.7.

10.5.2 Поддержка управления версиями и расширяемости

Часть пакета Digital Signature XML Signature НЕ ДОЛЖНА (SHALL NOT) содержать элементы или атрибуты пространства имён совместимости разметки, определённого в ECMA-376-3.

10.5.3 Элемент Signature

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.1 «XML-Signature Syntax and Processing».

Элемент Signature ДОЛЖЕН (SHALL) содержать ровно один специфический для OPC элемент Object и ноль или более определяемых приложением элементов Object.

10.5.4 Элемент SignedInfo

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3 «XML-Signature Syntax and Processing».

Элемент SignedInfo ДОЛЖЕН (SHALL) содержать ровно один элемент Reference, ссылающийся на специфический для OPC элемент Object. Элемент SignedInfo также МОЖЕТ (MAY) содержать один или более элементов Reference, ссылающихся на другие объекты данных.

10.5.5 Элемент CanonicalizationMethod

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3.1 «XML-Signature Syntax and Processing».

Пакеты ДОЛЖНЫ (SHALL) использовать только следующие методы каноникализации:

• XML Canonicalization (c14n)
• XML Canonicalization with Comments (c14n with comments)

10.5.6 Элемент SignatureMethod

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3.2 «XML-Signature Syntax and Processing».

Элемент SignatureMethod СЛЕДУЕТ (SHOULD) задавать один из следующих алгоритмов:

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

Длина ключа алгоритмов RSA SHA ДОЛЖНА (SHALL) быть равна 1 024 битам или более и СЛЕДУЕТ (SHOULD), чтобы она была равна 2 048 битам или более. СЛЕДУЕТ (SHOULD) использовать алгоритмы ECDSA, приведённые в NIST SP 800-56A Rev. 3, приложении D (см. ссылку [6]). Максимальная целевая криптостойкость СЛЕДУЕТ (SHOULD) быть не менее 128.

Этот элемент НЕ СЛЕДУЕТ (SHOULD NOT) задавать:

• http://www.w3.org/2000/09/xmldsig#dsa-sha1
• http://www.w3.org/2000/09/xmldsig#rsa-sha1
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1

Этот элемент МОЖЕТ (MAY) задавать другие алгоритмы.

10.5.7 Элемент Reference

10.5.7.1 Общие положения

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3.3 «XML-Signature Syntax and Processing».

10.5.7.2 Элемент Reference как дочерний элемент элемента SignedInfo

Элементы Reference внутри элемента SignedInfo ДОЛЖНЫ (SHALL) ссылаться только на элементы в пределах того же элемента Signature и СЛЕДУЕТ (SHOULD), чтобы они ссылались на элемент Object.

10.5.7.3 Элемент Reference как дочерний элемент элемента Manifest

Каждый элемент Reference, являющийся дочерним элементом элемента Manifest, ДОЛЖЕН (SHALL) ссылаться только на части пакета в пакете. Значением атрибута URI ДОЛЖНО (SHALL) быть имя части пакета без идентификатора фрагмента.

Ссылки на части пакета ДОЛЖНЫ (SHALL) включать тип носителя части пакета как компонент запроса. Синтаксис относительной ссылки имеет следующий вид:

где value — тип носителя целевой части пакета без учёта регистра.

ПРИМЕР Ссылка на часть пакета с компонентом запроса

В следующем примере тип носителя:

application/vnd.openxmlformats-
package.relationships+xml

URI="/_rels/document.xml.rels?ContentType=application/vnd.openxmlformats-
package.relationships+xml" 

10.5.8 Элемент Transform

10.5.8.1 Общие положения

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3.3.4 «XML-Signature Syntax and Processing».

ДОЛЖЕН (SHALL) быть задан один из следующих алгоритмов преобразования:

• XML Canonicalization (c14n)
• XML Canonicalization with Comments (c14n with comments)
• Преобразование Relationships (специфическое для OPC)

10.5.8.2 Элемент Transform, представляющий преобразование Relationships

Элемент Transform представляет преобразование Relationships, если значение его атрибута Algorithm равно:

Такой элемент Transform ДОЛЖЕН (SHALL):

• содержать один или более элементов RelationshipReference или RelationshipsGroupReference;
• быть элементом-потомком элемента Manifest;
• за которым следует элемент Transform, задающий XML Canonicalization (c14n) или XML Canonicalization with Comments (c14n with comments).

Преобразование Relationships описывает, как элементы Relationship из части пакета Relationships выбираются для подписания. Для конкретной части пакета Relationships ДОЛЖНО (SHALL) быть задано только одно преобразование Relationships. Подробные сведения об алгоритме приведены в 10.6.

10.5.9 Элемент RelationshipReference

Элемент RelationshipReference задаёт, какой элемент Relationship подписывается, и ДОЛЖЕН (SHALL) встречаться только как дочерний элемент элемента Transform, представляющего преобразование Relationships (10.5.8.2). Этот элемент специфичен для OPC.

Определение W3C XML Schema модели содержимого этого элемента является сложным типом CT_RelationshipReference, который определён в схеме opc-digSig.xsd (C.2).

10.5.10 Элемент RelationshipsGroupReference

Элемент RelationshipsGroupReference задаёт, что подписывается группа элементов Relationship с указанным значением атрибута Type. Этот элемент ДОЛЖЕН (SHALL) встречаться только как дочерний элемент элемента Transform, представляющего преобразование Relationships (10.5.8.2). Этот элемент специфичен для OPC.

Определение W3C XML Schema модели содержимого этого элемента является сложным типом CT_RelationshipsGroupReference, который определён в схеме opc-digSig.xsd (C.2).

10.5.11 Элемент DigestMethod

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.3.3.5 «XML-Signature Syntax and Processing».

Элемент DigestMethod СЛЕДУЕТ (SHOULD) задавать один из следующих алгоритмов:

• http://www.w3.org/2001/04/xmlenc#sha256
• http://www.w3.org/2001/04/xmldsig-more#sha384
• http://www.w3.org/2001/04/xmlenc#sha512

Этот элемент НЕ СЛЕДУЕТ (SHOULD NOT) задавать:

• http://www.w3.org/2000/09/xmldsig#sha1

Этот элемент НЕ ДОЛЖЕН (SHALL NOT) задавать:

• http://www.w3.org/2001/04/xmldsig-more#md5

Этот элемент МОЖЕТ (MAY) задавать другие алгоритмы.

10.5.12 Элемент Object

10.5.12.1 Общие положения

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.5 «XML-Signature Syntax and Processing». Элемент Object ДОЛЖЕН (SHALL) быть либо специфичным для OPC, либо определяемым приложением.

10.5.12.2 Специфический для OPC элемент Object

Специфический для OPC элемент Object ДОЛЖЕН (SHALL) содержать элемент Manifest, за которым следует элемент SignatureProperties, и не содержать других элементов. Атрибут Id специфического для OPC элемента Object ДОЛЖЕН (SHALL) быть задан, а его значением ДОЛЖНО (SHALL) быть "idPackageObject".

10.5.12.3 Определяемый приложением элемент Object

Определяемый приложением элемент Object задаёт информацию, определяемую приложением. Атрибут Id определяемого приложением элемента Object ДОЛЖЕН (SHALL) отсутствовать или иметь значение, отличное от "idPackageObject".

Реализациям СЛЕДУЕТ (SHOULD) избегать значений (таких как "idOfficeObject"), которые широко используются.

10.5.13 Элемент Manifest

Настоящий документ вводит дополнительные требования к требованиям, определённым в 4.4 «XML-Signature Syntax and Processing», только когда элемент Manifest является дочерним элементом специфического для OPC элемента Object. Элементы Reference в таком элементе Manifest ДОЛЖНЫ (SHALL) удовлетворять требованиям, определённым в 10.5.7.3.

10.5.14 Элемент SignatureProperty

Настоящий документ вводит дополнительные требования к требованиям, определённым в 5.2 «XML-Signature Syntax and Processing», только в случае, когда элемент SignatureProperty является дочерним элементом дочернего элемента SignatureProperties OPC-специфичного элемента Object. Такой элемент SignatureProperty ДОЛЖЕН (SHALL) задавать для атрибута Id значение "idSignatureTime", а также ДОЛЖЕН (SHALL) содержать элемент SignatureTime и не содержать других элементов. Значение атрибута Target такого элемента SignatureProperty ДОЛЖНО (SHALL) быть либо пустым, либо содержать ссылку на фрагмент значения атрибута Id корневого элемента Signature.

10.5.15 Элемент SignatureTime

Элемент SignatureTime содержит заявленную метку даты/времени для подписи. Этот элемент является OPC-специфичным.

Этот элемент не имеет атрибутов.

Определением W3C XML Schema модели содержимого этого элемента является сложный тип CT_SignatureTime, определённый в схеме opc-digSig.xsd (C.2).

10.5.16 Элемент Format

Элемент Format задаёт формат метки даты/времени. Этот элемент является OPC-специфичным. Формат даты/времени ДОЛЖЕН (SHALL) соответствовать синтаксису, описанному в примечании W3C «Date and Time Formats» (см. ссылку [2]).

Этот элемент не имеет атрибутов.

Определением W3C XML Schema модели содержимого этого элемента является ST_Format, определённый в схеме opc-digSig.xsd (C.2).

10.5.17 Элемент Value

Элемент Value ДОЛЖЕН (SHALL) содержать значение метки даты/времени. Этот элемент является OPC-специфичным. Значение ДОЛЖНО (SHALL) соответствовать формату, заданному в элементе Format.

Этот элемент не имеет атрибутов.

Определением W3C XML Schema модели содержимого этого элемента является ST_Value, определённый в схеме opc-digSig.xsd (C.2).

10.5.18 Элемент XPath

Элемент XPath НЕ ДОЛЖЕН (SHALL NOT) присутствовать. Следует отметить, что элемент XPath предназначен только для фильтрации XPath, которая в OPC запрещена.

10.6 Алгоритм преобразования Relationships

Преобразование Relationships получает XML-документ из указанной части Relationships и преобразует его в другой XML-документ. Это преобразование ДОЛЖНО (SHALL) поддерживаться при формировании и проверке подписей.

Следует отметить, что выходной XML-документ затем канонизируется указанным алгоритмом канонизации.

Преобразование Relationships ДОЛЖНО (SHALL) иметь следующие шаги:

Шаг 1: Обработка инструкций версионирования

Обработайте часть Relationships, как указано в ECMA-376-3, где конфигурация разметки пуста, а конфигурация приложения содержит только пространство имён Relationships.

Шаг 2: Сортировка и выбор подписываемых связей

a)

Удалите все объявления пространств имён, кроме объявления пространства имён Relationships.

b)

Удалите префикс пространства имён Relationships, если он присутствует.

c)

Отсортируйте элементы Relationship по значению Id в лексикографическом порядке с учётом регистра.
Сохраните только те элементы Relationship, которые либо имеют значение Id, совпадающее со значением SourceId элемента RelationshipReference, либо имеют значение Type, совпадающее со значением SourceType элемента RelationshipGroupReference, заданного в преобразовании Relationships. Сопоставление выполняется без учёта регистра ASCII.

ПРИМЕР Рассмотрим часть Relationships

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<rlsps:Relationships 
xmlns:rlsps="http://schemas.openxmlformats.org/package/2006/relationships" 
xmlns:foo="http://example.com/foo"> 
    <rlsps:Relationship Id="rId6" Type="http://../relationships/footnotes" 
Target="footnotes.xml"/> 
    <rlsps:Relationship Id="rId8" Type="http://../relationships/header" 
Target="header1.xml"/> 
    <rlsps:Relationship Id="rId32" Type="http://../relationships/image" 
Target="media/image1.png"/> 
    <rlsps:Relationship Id="rId3" Type="http://../relationships/styles" 
Target="styles.xml"/> 
    <rlsps:Relationship Id="rId21" Type="http://../relationships/image" 
Target="media/image2.jpeg"/> 
    <rlsps:Relationship Id="rId12" Type="http://../relationships/header" 
Target="header1.xml"/> 
</rlsps:Relationships> 

При Id="rId6" и Type="http://../relationships/image" шаг 2 формирует

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<Relationships 
xmlns="http://schemas.openxmlformats.org/package/2006/relationships"> 
    <Relationship Id="rId21" Type="http://../relationships/image" 
Target="media/image2.jpeg"/> 

    <Relationship Id="rId32" Type="http://../relationships/image" 
Target="media/image1.png"/> 
    <Relationship Id="rId6" Type="http://../relationships/footnotes" 
Target="footnotes.xml"/>     
</Relationships> 

Шаг 3: Подготовка к канонизации

a)

Удалите все текстовые узлы и комментарии в XML-документе.

b)

Если атрибут TargetMode отсутствует у элемента Relationship, добавьте его со значением по умолчанию "Internal".

10.7 Пример цифровой подписи

Разметка цифровой подписи для пакетов показана в этом примере. Сведения о пространствах имён, используемых в этом примере, см. в приложении E. Следует отметить, что префикс пространства имён «pds» обозначает пространство имён OPC-специфичных элементов в цифровых подписях.

В этом примере имеются два элемента Object. Первый элемент Object является OPC-специфичным, поскольку значение его атрибута Id равно "idPackageObject". Второй элемент Object (в самом конце этого примера) является зависящим от приложения, поскольку значение его атрибута Id не равно "idPackageObject".

OPC-специфичный элемент Object содержит элемент Manifest, за которым следует элемент SignatureProperties. Элемент Manifest задаёт список частей пакета своими дочерними элементами Reference. Первый элемент Reference ссылается на часть пакета "/document.xml" посредством значения атрибута URI. Второй элемент Reference ссылается на часть Relationships "/_rels/document.xml.rels", исходной частью которой является "/document.xml".

Дочерние элементы этих элементов Reference задают используемые преобразование и метод вычисления дайджеста, а также полученные значения дайджеста. Следует отметить, что первым преобразованием для части Relationships является преобразование Relationships.

Элемент SignedInfo (в начале этого примера) ссылается на два элемента Object. OPC-специфичный элемент Object, включая его дочерние элементы Manifest и SignatureProperties, канонизируется, а затем подписывается. Определённый приложением элемент Object также подписывается.

Элемент SignatureValue содержит подпись, а элемент KeyInfo содержит сертификат X509.

<Signature Id="SignatureId" xmlns="http://www.w3.org/2000/09/xmldsig#"> 
   <SignedInfo> 
      <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/ 
         REC-xml-c14n-20010315"/> 
      <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-
sha1"/> 
      <Reference  

         URI="#idPackageObject"  
         Type="http://www.w3.org/2000/09/xmldsig#Object"> 
         <Transforms> 
            <Transform Algorithm="http://www.w3.org/TR/2001/ 
               REC-xml-c14n-20010315"/> 
         </Transforms> 
         <DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
         <DigestValue>…</DigestValue> 
      </Reference> 
      <Reference  
         URI="#Application"  
         Type="http://www.w3.org/2000/09/xmldsig#Object"> 
         <Transforms> 
            <Transform Algorithm="http://www.w3.org/TR/2001/ 
               REC-xml-c14n-20010315"/> 
         </Transforms> 
         <DigestMethod  
            Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
         <DigestValue>…</DigestValue> 
      </Reference> 
   </SignedInfo> 
   <SignatureValue>…</SignatureValue> 
 
   <KeyInfo> 
      <X509Data> 
         <X509Certificate>…</X509Certificate> 
      </X509Data> 
   </KeyInfo> 
 
   <Object Id="idPackageObject" 
xmlns:pds="http://schemas.openxmlformats.org/ 
      package/2006/digital-signature"> 
      <Manifest> 
         <Reference URI="/document.xml?ContentType=application/ 
            vnd.ms-document+xml"> 
            <Transforms> 
               <Transform Algorithm="http://www.w3.org/TR/2001/ 
                  REC-xml-c14n-20010315"/> 
            </Transforms> 
            <DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
            <DigestValue>…</DigestValue> 
         </Reference> 
         <Reference  

            URI="/_rels/document.xml.rels?ContentType=application/ 
               vnd.openxmlformats-package.relationships+xml"> 
            <Transforms> 
               <Transform Algorithm="http://schemas.openxmlformats.org/ 
                  package/2006/RelationshipTransform"> 
                  <pds:RelationshipReference SourceId="B1"/> 
                  <pds:RelationshipReference SourceId="A1"/> 
                  <pds:RelationshipReference SourceId="A11"/> 
                  <pds:RelationshipsGroupReference SourceType= 
                     "http://schemas.example.com/required-resource"/> 
               </Transform> 
               <Transform Algorithm="http://www.w3.org/TR/2001/ 
                  REC-xml-c14n-20010315"/> 
            </Transforms> 
            <DigestMethod 
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> 
            <DigestValue>…</DigestValue> 
         </Reference> 
      </Manifest> 
      <SignatureProperties> 
         <SignatureProperty Id="idSignatureTime" Target="#SignatureId"> 
            <pds:SignatureTime> 
               <pds:Format>YYYY-MM-DDThh:mmTZD</pds:Format> 
               <pds:Value>2003-07-16T19:20+01:00</pds:Value> 
            </pds:SignatureTime> 
         </SignatureProperty>  
      </SignatureProperties> 
   </Object> 
   <Object Id="Application">…</Object> 
</Signature> 

10.8 Формирование подписей

При формировании пакетов с цифровой подписью ДОЛЖНЫ (SHALL) использоваться формирование ссылок и формирование подписей, как описано в 3.1 «XML-Signature Syntax and Processing», с некоторыми изменениями для OPC-специфичных конструкций, указанными в настоящем подпункте.

ПРИМЕЧАНИЕ Приведённые ниже шаги не применяются к формированию подписей, содержащих определённые приложением элементы Object.

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

Формирование ссылок:

a)

Для каждой подписываемой части пакета создайте элемент Reference, следуя шагам в 3.1.1 «XML-Signature Syntax and Processing».

b)

Сконструируйте OPC-специфичный элемент Object, содержащий элемент Manifest как с дочерними элементами Reference, полученными на предыдущем шаге, так и с дочерним элементом SignatureProperties , который, в свою очередь, содержит дочерний элемент SignatureTime.

c)

Создайте ссылку на результирующий OPC-специфичный элемент Object, следуя шагам в 3.1.1 «XML-Signature Syntax and Processing».

Формирование ссылок ДОЛЖНО (SHALL) поддерживать следующие алгоритмы вычисления дайджеста:

• http://www.w3.org/2001/04/xmlenc#sha256
• http://www.w3.org/2001/04/xmldsig-more#sha384
• http://www.w3.org/2001/04/xmlenc#sha512

Формирование ссылок НЕ СЛЕДУЕТ (SHOULD NOT) поддерживать

• http://www.w3.org/2000/09/xmldsig#sha1

Формирование ссылок НЕ ДОЛЖНО (SHALL NOT) поддерживать

• http://www.w3.org/2001/04/xmldsig-more#md5

Формирование ссылок МОЖЕТ (MAY) поддерживать другие алгоритмы.

Формирование подписи:

Следуйте шагам в 3.1.2 «XML-Signature Syntax and Processing».

Формирование подписи ДОЛЖНО (SHALL) поддерживать следующие алгоритмы:

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

В случае алгоритмов RSA SHA формирование подписи ДОЛЖНО (SHALL) поддерживать длины ключей, большие или равные 2 048. Оно НЕ СЛЕДУЕТ (SHOULD NOT) поддерживать длины ключей менее 2 048 битов и НЕ ДОЛЖНО (SHALL NOT) поддерживать длины ключей менее 1 024 битов. В случае алгоритмов ECDSA формирование подписи СЛЕДУЕТ (SHOULD) поддерживать эллиптические кривые, определённые в FIPS 186-4 как P-256, P-384 и P-521, но НЕ СЛЕДУЕТ (SHOULD NOT) поддерживать P-224.

Формирование подписи НЕ СЛЕДУЕТ (SHOULD NOT) поддерживать:

• http://www.w3.org/2000/09/xmldsig#dsa-sha1
• http://www.w3.org/2000/09/xmldsig#rsa-sha1
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1

Формирование подписи МОЖЕТ (MAY) поддерживать другие алгоритмы.

10.9 Проверка подписей

При проверке пакетов с цифровой подписью ДОЛЖНЫ (SHALL) использоваться проверка ссылок и проверка подписей, как описано в 3.2 «XML-Signature Syntax and Processing», с некоторыми изменениями для OPC-специфичных конструкций, указанными в настоящем подпункте.

ПРИМЕЧАНИЕ Приведённые ниже шаги не применяются к проверке подписей, содержащих определённые приложением элементы Object.

Сертификат, встроенный в элемент KeyInfo части XML Signature цифровой подписи, ДОЛЖЕН (SHALL) использоваться, если он указан.

Проверка ссылок:

Сначала проверьте ссылку на OPC-специфичный элемент Object, следуя шагам в 3.2.2 «XML-Signature Syntax and Processing».

Затем для каждой ссылки в элементе Manifest:

a)

проверьте ссылку, следуя шагам в 3.2.2 «XML-Signature Syntax and Processing»;

b)

проверьте тип носителя части пакета, на которую дана ссылка, по типу носителя, заданному в компоненте запроса ссылки. Ссылки недействительны, если эти два значения различаются. Сравнение строк ДОЛЖНО (SHALL) выполняться без учёта регистра.

Проверка ссылок ДОЛЖНА (SHALL) поддерживать следующие алгоритмы вычисления дайджеста:

• http://www.w3.org/2001/04/xmlenc#sha256
• http://www.w3.org/2001/04/xmldsig-more#sha384
• http://www.w3.org/2001/04/xmlenc#sha512

Проверка ссылок НЕ ДОЛЖНА (SHALL NOT) поддерживать

• http://www.w3.org/2001/04/xmldsig-more#md5

Проверка ссылок МОЖЕТ (MAY) поддерживать другие алгоритмы, включая

• http://www.w3.org/2000/09/xmldsig#sha1

Проверка подписи:

Следуйте шагам в 3.2.2 «XML-Signature Syntax and Processing».

Проверка подписи ДОЛЖНА (SHALL) поддерживать следующие алгоритмы, заданные элементами SignatureMethod:

• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha512
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha384
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha512

В случае алгоритмов RSA SHA проверка подписи ДОЛЖНА (SHALL) поддерживать длины ключей, большие или равные 2 048 битам. Она НЕ ДОЛЖНА (SHALL NOT) поддерживать длины ключей менее 1 024 битов. Она МОЖЕТ (MAY) поддерживать длины ключей, большие или равные 1 024 битам и менее 2 048 битов. В случае алгоритмов ECDSA проверка подписи ДОЛЖНА (SHALL) поддерживать эллиптические кривые, определённые в FIPS 186-4 как P-256, P-384 и P-521, но НЕ СЛЕДУЕТ (SHOULD NOT) поддерживать P-224.

Проверка подписи МОЖЕТ (MAY) поддерживать другие алгоритмы, включая:

• http://www.w3.org/2000/09/xmldsig#dsa-sha1
• http://www.w3.org/2000/09/xmldsig#rsa-sha1
• http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1

Приложение A
(справочное)
Предварительная обработка для формирования относительных ссылок

Относительные ссылки доступны для ссылок на части пакета. Для ссылок на части пакета также используются строки Unicode, похожие на относительные ссылки, но не являющиеся ими в строгом смысле. Например, "\a.xml" не является относительной ссылкой, поскольку символ обратной косой черты не допускается в RFC 3986 или RFC 3987.

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

• Выполнить процентное кодирование каждой открывающей скобки («[») и закрывающей скобки («]»).
• Выполнить процентное кодирование каждого символа пробела (U+0020).
• Выполнить процентное кодирование каждого символа процента («%»), за которым не следует шестнадцатеричное обозначение значения октета.
• Декодировать процентное кодирование каждого незарезервированного символа, закодированного с помощью процента.
• Декодировать процентное кодирование каждой прямой косой черты («/») и обратной косой черты («\»).
• Преобразовать все обратные косые черты в прямые косые черты.
• Если они присутствуют в сегменте, содержащем символы, отличные от точки («.»), удалить завершающие символы точки («.») из каждого сегмента.
• Заменить каждое вхождение нескольких последовательных прямых косых черт («/») одной прямой косой чертой.
• При наличии единственной завершающей прямой косой черты («/») удалить эту завершающую прямую косую черту.
• Удалить целые сегменты, состоящие из трёх или более точек.

Примеры строк Unicode, преобразованных в относительные ссылки, приведены ниже:

Приложение B
(нормативное)
Ограничения и разъяснения по использованию возможностей ZIP

B.1 Общие положения

Настоящее приложение устанавливает требования и рекомендации относительно возможностей формата ZIP. ZIP-файл, представляющий физический пакет, ДОЛЖЕН (SHALL) удовлетворять установленным требованиям и также СЛЕДУЕТ (SHOULD) соблюдать установленные рекомендации.

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

B.2 Согласованность заголовков архивного файла

Данные, описывающие файлы, хранящиеся в архиве, в значительной степени дублируются в локальных заголовках файлов (Local File Headers) и дескрипторах данных (Data Descriptors), а также в заголовках файлов (File headers) в записи центрального каталога (Central Directory Record). Чтобы ZIP-файл являлся физическим уровнем для пакета, реализатор пакета ДОЛЖЕН (SHALL) обеспечить, чтобы ZIP-файл содержал равные значения в соответствующих полях каждого заголовка файла в центральном каталоге и соответствующей пары локального заголовка файла и дескриптора данных, когда дескриптор данных существует, за исключением описанного в таблице B.5 для бита 3 флагов общего назначения.

B.3 Сигнатура дескриптора данных

Пакеты МОГУТ (MAY) содержать 4-байтовое значение сигнатуры 0x08074b50 в начале дескрипторов данных, непосредственно перед полем crc-32. Реализаторам пакетов СЛЕДУЕТ (SHOULD) уметь читать пакеты независимо от наличия сигнатуры.

B.4 Требования к реализаторам пакетов

Поля в таблицах настоящего подраздела содержат следующие значения:

• «Да» — при потреблении пакета значение «Да» для поля в таблице настоящего приложения означает, что реализатор пакета НЕ ДОЛЖЕН (SHALL NOT) завершать работу с ошибкой при чтении ZIP-файла, содержащего эту запись или поле; однако поле МОЖЕТ (MAY) быть проигнорировано. При формировании пакета значение «Да» для поля в таблице настоящего приложения означает, что реализатор пакета ДОЛЖЕН (SHALL) записать эту запись или поле.

• «Нет» — значение «Нет» для поля в таблице настоящего приложения означает, что реализатору пакета НЕ СЛЕДУЕТ (SHOULD NOT) использовать эту запись или поле.

• «Необязательно» — значение «Необязательно» для записи в таблице настоящего приложения означает, что реализаторы пакетов МОГУТ (MAY) записывать эту запись при формировании.

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

• «Используется только при необходимости» — значение «Используется только при необходимости», связанное с записью в таблице настоящего приложения, означает, что реализатор пакета ДОЛЖЕН (SHALL) использовать эту запись только при необходимости хранения данных в ZIP-файле.

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

Таблица B.2 устанавливает требования к формированию, потреблению и редактированию пакета в отношении отдельных компонентов записей, описанных в ZIP Appnote.

Таблица B.3 устанавливает подробные требования к формированию, потреблению и редактированию для поля «Версия, необходимая для извлечения», которое полностью описано в ZIP Appnote.

В таблице B.4 приведены подробные требования к созданию, потреблению и редактированию для поля Compression Method, которое полностью описано в ZIP Appnote.

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

В таблице B.6 приведены подробные требования к созданию, потреблению и редактированию для записей поля Extra, зарезервированных PKWARE и описанных в ZIP Appnote.

В таблице B.7 приведены подробные требования к созданию, потреблению и редактированию для записей поля Extra, зарезервированных третьими сторонами и описанных в ZIP Appnote.

Реализатор пакета ДОЛЖЕН (SHALL) обеспечить, чтобы для всех размеров и смещений записей 64-битных потоков старший бит был равен 0.

Реализатор пакета ДОЛЖЕН (SHALL) обеспечить, чтобы все поля, содержащие «number of entries», не превышали 2 147 483 647.

Приложение C
(нормативное)
Схемы — W3C XML

C.1 Общие положения

Настоящий документ сопровождается семейством схем, определённых с использованием синтаксиса, заданного в «W3C XML Schema Structures» и «W3C XML Schema Datatypes». Эту спецификацию сопровождает ZIP-файл OpenPackagingConventions-XMLSchema.zip, содержащий все схемы.

C.2 Поток Media Types

См. файл opc-contentTypes.xsd.

C.3 Часть пакета Core Properties

См. файл opc-coreProperties.xsd.

C.4 Разметка XML-подписи цифровой подписи

См. файл opc-digSig.xsd.

C.5 Часть пакета Relationships

См. файл opc-relationships.xsd.

Приложение D
(справочное)
Схемы — RELAX NG

D.1 Общие положения

Настоящий документ сопровождается семейством схем, определённых с использованием синтаксиса RELAX NG. Эту спецификацию сопровождает ZIP-файл OpenPackagingConventions-RELAXNG.zip, содержащий все схемы.

Если между версией схемы RELAX NG и соответствующей ей схемой XSD существуют расхождения, определяющей версией является схема XSD.

D.2 Поток Media Types

См. файл opc-contentTypes.rnc.

D.3 Часть пакета Core Properties

См. файл opc-coreProperties.rnc.

Схема доступна по адресу: http://standards.iso.org/iso-iec/29500/-2/ed-4/en/OpenPackagingConventions-RELAXNG/opc-coreProperties.rnc.

D.4 Разметка XML-подписи цифровой подписи

См. файлы opc-digSig.rnc и security_any.rnc.

D.5 Часть пакета Relationships

См. файл opc-relationships.rnc.

Эта схема доступна по адресу: http://standards.iso.org/iso-iec/29500/-2/ed-4/en/OpenPackagingConventions-RELAXNG/opc-relationships.rnc.

D.6 Дополнительные ресурсы

D.6.1 XML

См. файл xml.rnc.

D.6.2 Ядро цифровой подписи XML

См. файл xmldsig-core-schema.rnc.

Приложение E
(нормативное)
Стандартные пространства имён и типы носителей

Пространства имён, доступные для использования в пакете, перечислены в таблице E.1.

Типы носителей для частей пакета, определённых в настоящем документе, перечислены в таблице E.2.

Типы связей, доступные для использования в пакете, перечислены в таблице E.3.

Приложение F
(информативное)
Особенности проектирования физической модели пакета

F.1 Общие положения

Физическая модель пакета определяет способы создания и использования пакетов. Эта модель основана на трёх компонентах: производителе, потребителе и канале между ними, как показано на рисунке F.1.

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

При локальном доступе канал передаёт данные непосредственно от производителя к потребителю на одном устройстве.

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

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

F.2 Стили доступа

F.2.1 Общие положения

Стиль доступа, в котором осуществляется локальный или сетевой доступ, определяет возможную одновременность операций обработки и ввода-вывода.

F.2.2 Потребление с прямым доступом

Потребление с прямым доступом позволяет потребителям запрашивать требуемую конкретную часть пакета без последовательной обработки предшествующих частей пакета. Например, запрос диапазона байтов. Это наиболее распространённый стиль доступа.

F.2.3 Потоковое потребление

Потоковое потребление позволяет потребителям начать обработку частей пакета до поступления всего пакета. Физические форматы СЛЕДУЕТ (SHOULD) проектировать так, чтобы потребители могли начать интерпретацию и обработку получаемых ими данных до того, как через канал будут переданы все биты пакета.

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

Однако для обеспечения потокового потребления рекомендуется, чтобы поток Media Types не содержал Default элементов. Поток Media Types СЛЕДУЕТ (SHOULD) снабжать одним Override элементом для каждой части пакета. Каждый Override элемент СЛЕДУЕТ (SHOULD) располагать перед соответствующей ему частью пакета либо в непосредственной близости от неё.

F.2.4 Потоковое создание

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

Для поддержки потокового создания реализатору пакета СЛЕДУЕТ (SHOULD) позволять производителю добавлять части пакета после того, как уже были добавлены другие части пакета. Потребитель НЕ ДОЛЖЕН (SHALL NOT) требовать от производителя указания количества частей пакета, которые он создаст, в начале записи. Реализатору пакета СЛЕДУЕТ (SHOULD) позволять производителю начинать запись содержимого части пакета, не зная её окончательной длины.

F.2.5 Одновременное создание и потребление

Одновременное создание и потребление позволяют потоковому созданию и потоковому потреблению происходить одновременно для пакета. Ввиду преимуществ, которые могут быть достигнуты в использующих это конвейерных архитектурах, реализатору пакета СЛЕДУЕТ (SHOULD) поддерживать одновременное создание и потребление в физическом пакете.

F.3 Стили размещения

F.3.1 Общие положения

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

F.3.2 Простое упорядочение

При простом упорядочении части пакета располагаются непрерывно. Когда пакет передаётся последовательно, сначала поступают все байты первой части пакета, затем все байты второй части пакета и так далее. Если такой пакет использует простое упорядочение, все байты каждой части пакета хранятся непрерывно.

ПРИМЕР Узкое место производительности при простом упорядочении

На рисунке F.2 показаны две части пакета: часть пакета страницы (markup/page.xml), описывающая содержимое страницы, и часть пакета изображения (images/picture.jpeg), ссылающаяся на изображение, отображаемое на странице. При простом упорядочении все байты части пакета страницы передаются до байтов части пакета изображения.

Рисунок F.2 иллюстрирует этот сценарий. Изображение не может быть отображено, пока не будут получены вся часть пакета страницы и часть пакета изображения. В некоторых обстоятельствах, например для небольших пакетов в высокоскоростной сети, это может быть приемлемо. В других случаях необходимость прочитать весь markup/page.xml, чтобы перейти к изображению, приводит к неприемлемой производительности или создаёт чрезмерные требования к памяти.

F.3.3 Перемежаемое упорядочение

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

Разбивая части пакета на фрагменты и перемежая эти фрагменты, можно оптимизировать производительность, обеспечивая при этом лёгкое восстановление исходной непрерывной части пакета.

Благодаря обеспечиваемым им преимуществам в производительности реализаторам пакета СЛЕДУЕТ (SHOULD) поддерживать перемежение в физическом пакете. Часть пакета, разбитая в физическом файле на несколько фрагментов, считается одной логической частью пакета; сами фрагменты не являются частями пакета и не могут адресоваться.

F.4 Стили связи

F.4.1 Общие положения

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

F.4.2 Последовательная доставка

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

F.4.3 Произвольный доступ

Произвольный доступ позволяет потребителям запрашивать доставку части пакета вне последовательного физического порядка. Некоторые каналы основаны на протоколах, способных обеспечивать произвольный доступ, например HTTP 1.1 с поддержкой диапазонов байтов. Для достижения максимальной производительности реализатору пакета СЛЕДУЕТ (SHOULD) поддерживать произвольный доступ как в канале, так и в физическом пакете. При отсутствии такой поддержки потребителям необходимо ждать, пока нужные им части пакета будут доставлены последовательно.

Приложение G
(информативное)
Различия между ECMA-376-2021 и ECMA-376:2006

G.1 Общие положения

В настоящем приложении документированы синтаксические различия между версиями соглашений об открытой упаковке, определёнными в настоящем документе и в ECMA-376:2006 (см. ссылку [5]).

G.2 Элементы XML

Следующий элемент XML включён в настоящий документ, но не включён в ECMA-376:2006:

• элемент value (8.3.4.4.4)

Следующий элемент XML включён в ECMA-376:2006, но не включён в настоящий документ:

• элемент contentType

G.3 Атрибуты XML

Изменений нет.

G.4 Значения перечислений XML

Изменений нет.

G.5 Простые типы XML

Изменений нет.

G.6 Имена частей пакета

Имена частей пакета, содержащие символы, не входящие в ASCII, разрешены настоящим документом, но запрещены ECMA-376:2006.

Приложение H
(информативное)
Пример пакета

H.1 Общие положения

В настоящем приложении показаны абстрактный пакет и физический пакет, представляющие документ Microsoft® Office.

H.2 Абстрактный пакет

Этот абстрактный пакет содержит пять частей пакета: "/_rels/.rels, /docProps/core.xml", "/word/_rels/document.xml.rels", "/word/document.xml" и "/word/settings.xml".

См. рисунок H.1.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<Relationships 
xmlns="http://schemas...org/package/2006/relationships"> 
    <Relationship Id="rId2" 
        Type="http://schemas... " 
        Target="docProps/core.xml"/> 
    <Relationship Id="rId1"  
        Type="http://schemas... " 
        Target="word/document.xml"/> 
</Relationships>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<Relationships 
xmlns="http://schemas...org/package/2006/relationships"> 
    <Relationship Id="rId2" 
        Type="http://schemas... " 
        Target="settings.xml"/> 
</Relationships>

Две из этих частей пакета являются частями Relationships ("/_rels/.rels" и "/word/_rels/document.xml.rels"), а три — частями, не являющимися частями Relationships ("/word/document.xml", "/docProps/core.xml" и "/word/settings.xml"); при этом "_rels/.rels" является частью Relationships пакета, а "/word/_rels/document.xml.rels" — частью Relationships, связанной с "/word/document.xml". Часть Relationships пакета содержит две связи от пакета к "/docProps/core.xml" и "/word/document.xml" соответственно. Часть Relationships содержит связь от "/word/document.xml" к "/word/settings.xml".

H.3 Физический пакет

Этот физический пакет (empty.docx) является ZIP-файлом. Элементами ZIP в этом ZIP-файле являются "_rels/.rels", "docProps/core.xml", "word/_rels/document.xml.rels", "word/document.xml", "word/settings.xml" и "[Content_Types].xml".

За исключением "[Content_Types].xml", эти элементы ZIP представляют части пакета. Обратите внимание, что имена частей пакета начинаются с символа "/". "[Content_Types].xml" представляет поток Media Types.

Библиография

[1] Модель символов для Всемирной паутины: сопоставление строк, Примечание рабочей группы W3C, 04 февраля 2019 г., доступно по адресу https://www.w3.org/TR/2019/NOTE-charmod-norm-20190204/

[2] Форматы даты и времени, W3C NOTE 19980827, 1997, доступно по адресу http://www.w3.org/TR/1998/NOTE-datetime-19980827

[3] Схемы RELAX NG для безопасности XML, Примечание рабочей группы W3C от 11 апреля 2013 г., доступно по адресу https://www.w3.org/TR/xmlsec-rngschema/

[4] ISO/IEC TR 30114-1, Информационные технологии — Расширения форматов файлов Office Open XML — часть 1: Руководящие указания, доступно по адресу https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

[5] ECMA-376:2006 Форматы файлов Office Open XML, 1-е издание (декабрь 2006 г.), доступно по адресу https://www.ecma-international.org/publications-and-standards/standards/ecma-376/

[6] NIST SP 800-56A Rev. 3, Рекомендация по схемам попарного установления ключей с использованием криптографии дискретного логарифма, доступно по адресу https://doi.org/10.6028/NIST.SP.800-56Ar3, апрель 2018 г.

[7] ISO/IEC 10646, Информационные технологии — Универсальный набор кодированных символов (UCS), доступно по адресу https://standards.iso.org

[8] Схемы унифицированного идентификатора ресурса (URI), доступно по адресу https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Лицензия Ecma: исходное уведомление

Разрешение на перевод: официальная политика Ecma.

COPYRIGHT NOTICE 
© Ecma International 
By obtaining and/or copying this work, you (the licensee) agree that you have read, understood, and will comply 
with the following terms and conditions. 
This document may be copied, published and distributed to others, and certain derivative works of it may be 
prepared, copied, published, and distributed, in whole or in part, provided that the above copyright notice and 
this Copyright License and Disclaimer are included on all such copies and derivative works. The only derivative 
works that are permissible under this Copyright License and Disclaimer are:  
(i) works which incorporate all or portion of this document for the purpose of providing commentary or  
 explanation (such as an annotated version of the document), 
(ii) works which incorporate all or portion of this document for the purpose of incorporating features that  
 provide accessibility, 
(iii) translations of this document into languages other than English and into different formats and  
(iv) works by making use of this specification in standard conformant products by implementing (e.g. by  
 copy and paste wholly or partly) the functionality therein. 
However, the content of this document itself may not be modified in any way, including by removing the 
copyright notice or references to Ecma International, except as required to translate it into languages other 
than English or into a different format. 
The official version of an Ecma International document is the English language version on the Ecma 
International website. In the event of discrepancies between a translated version and the official version, the 
official version shall govern. 
The limited permissions granted above are perpetual and will not be revoked by Ecma International or its 
successors or assigns. 
This document and the information contained herein is provided on an “AS IS” basis and ECMA 
INTERNATIONAL DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 
ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR 
A PARTICULAR PURPOSE.