Package Model

Table 1. H–1. Package model conformance requirements

ID

Rule

Reference

Package Implementer

Format Designer

Format Producer

Format Consumer

M1.1

The package implementer shall require a part name.

8.1, 8.1.1

×

M1.2

The package implementer shall require a content type and the format designer shall specify the content type.

8.1

×

×

M1.3

A part name shall not have empty segments.

0

×

M1.4

A part name shall start with a forward slash (“/”) character.

0

×

M1.5

A part name shall not have a forward slash as the last character.

0

×

M1.6

A segment shall not hold any characters other than pchar characters. .

0

×

M1.7

A segment shall not contain percent-encoded forward slash (“/”), or backward slash (“\”) characters.

0

×

M1.8

A segment shall not contain percent-encoded unreserved characters.

0

×

M1.9

A segment shall not end with a dot (“.”) character.

0

×

M1.10

A segment shall include at least one non-dot character

0

×

M1.11

A package implementer shall neither create nor recognize a part with a part name derived from another part name by appending segments to it.

8.1.1.1

×

M1.12

Part name equivalence is determined by comparing part names as case-insensitive ASCII strings. Packages shall not contain equivalent part names and package implementers shall neither create nor recognize packages with equivalent part names.

8.1.1.2

×

M1.13

Package implementers shall only create and only recognize parts with a content type; format designers shall specify a content type for each part included in the format. Content types for package parts shall fit the definition and syntax for media types as specified in RFC 2616, §3.7.

8.1.2

×

×

M1.14

Content types shall not use linear white space either between the type and subtype or between an attribute and its value. Content types also shall not have leading or trailing white spaces. Package implementers shall create only such content types and shall require such content types when retrieving a part from a package; format designers shall specify only such content types for inclusion in the format.

8.1.2

×

×

M1.15

The package implementer shall require a content type that does not include comments and the format designer shall specify such a content type.

8.1.2

×

×

M1.16

If the package implementer specifies a growth hint, it is set when a part is created and the package implementer shall not change the growth hint after the part has been created.

8.1.3

×

×

M1.17

XML content shall be encoded using either UTF-8 or UTF-16. If any part includes an encoding declaration, as defined in §4.3.3 of the XML 1.0 specification, that declaration shall not name any encoding other than UTF-8 or UTF-16. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.18

DTD declarations shall not be used in the XML markup defined in this Open Packaging specification. Package implementers shall enforce this requirement upon creation and retrieval of the XML content and shall treat the presence of DTD declarations as an error.

8.1.4

×

M1.19

If the XML content contains the Markup Compatibility namespace, as described in Part 5: “Markup Compatibility and Extensibility”, it shall be processed by the package implementer to remove Markup Compatibility elements and attributes, ignorable namespace declarations, and ignored elements and attributes before applying subsequent validation rules.

8.1.4

×

M1.20

XML content shall be valid against the corresponding XSD schema defined in this Open Packaging specification. In particular, the XML content shall not contain elements or attributes drawn from namespaces that are not explicitly defined in the corresponding XSD unless the XSD allows elements or attributes drawn from any namespace to be present in particular locations in the XML markup. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.21

XML content shall not contain elements or attributes drawn from “xml” or “xsi” namespaces unless they are explicitly defined in the XSD schema or by other means described in this Open Packaging specification. Package implementers shall enforce this requirement upon creation and retrieval of the XML content.

8.1.4

×

M1.22

Package implementers and format designers shall not create content types with parameters for the package-specific parts defined in this Open Packaging specification and shall treat the presence of parameters in these content types as an error.

Annex F

×

×

M1.23

XML markup might contain Unicode strings referencing other parts as values of the xsd:anyURI data type. Format consumers shall convert these Unicode strings to URIs, as defined in Annex A, “Resolving Unicode Strings to Part Names,” before resolving them relative to the base URI of the part containing the Unicode string.

8.2.1

×

M1.24

Some types of content provide a way to override the default base URI by specifying a different base in the content. In the presence of one of these overrides, format consumers shall use the specified base URI instead of the default.

8.2.1

×

M1.25

The Relationships part shall not have relationships to any other part. Package implementers shall enforce this requirement upon the attempt to create such a relationship and shall treat any such relationship as invalid.

8.3.1

×

M1.26

The package implementer shall require that every Relationship element has an Id attribute, the value of which is unique within the Relationships part, and that the Id type is xsd:ID, the value of which conforms to the naming restrictions for xsd:ID as described in the W3C Recommendation “XML Schema Part 2: Datatypes.”

8.3.3

×

M1.27

The package implementer shall require the Type attribute to be a URI that defines the role of the relationship and the format designer shall specify such a Type.

8.3.3.2

×

×

M1.28

The package implementer shall require the @Target attribute to be a URI reference pointing to a target resource. The URI reference shall be a URI or a relative reference.

8.3.3.2

×

M1.29

When set to Internal, the @Target attribute shall be a relative reference and that reference is interpreted relative to the “parent” part. For package relationships, the package implementer shall resolve relative references in the @Target attribute against the pack URI that identifies the entire package resource.

8.3.3.2

×

M1.30

The package implementer shall name relationship parts according to the special relationships part naming convention and require that parts with names that conform to this naming convention have the content type for a Relationships part

8.3.4

×

M1.31

Consumers shall process relationship markup in a manner that conforms to Part 5: “Markup Compatibility and Extensibility”. Producers editing relationships based on this version of the relationship markup specification shall not preserve any ignored content, regardless of the presence of any preservation attributes as defined in Part 5: “Markup Compatibility and Extensibility”.

8.3.5

×

×

M1.32

If a fragment identifier is allowed in the @Target attribute of the <Relationship> element, a package implementer shall not resolve the URI to a scope less than an entire part.

8.3.3.2

×

M1.33

A Unicode string representing a URI can be passed to the producer or consumer. The producing or consuming application shall convert the Unicode string to a URI. If the URI is a relative reference, the application shall resolve it using the base URI of the part, which is expressed using the pack scheme, to the URI of the referenced part.

Annex A

×

×

M1.34

If a consumer converts the URI back into an IRI, the conversion shall be performed as specified in §3.2 of RFC 3987.

A.2

×