DocumentID: ECMA-376/Part2/9.1.2
Title: ECMA-376, Part2: 9.1.2 Mapping Content Types
Extracted-From: ECMA-376 Office Open XML File Formats, 1st Edition / December 2006
Warning: Coverted to HTML format by a script known to have bugs

• Next: 9.1.3 Mapping Part Names to Physical Package Item Names
• Up: 9.1 Physical Mapping Guidelines
• Table of contents: Table of contents
• Previous: 9.1.1 Mapped Components

9.1.2 Mapping Content Types

Methods for mapping part content types to a physical format are described below.

9.1.2.1 Identifying the Part Content Type

The package implementer shall define a format mapping with a mechanism for associating content types with parts. [M2.3]

Some physical package formats have a native mechanism for representing content types. [Example: the content type header in MIME end example] For such packages, the package implementer should use the native mechanism to map the content type for a part. [S2.1]

For all other physical package formats, the package implementer should include a specially-named XML stream in the package called the Content Types stream. [S2.2] The Content Types stream shall not be mapped to a part by the package implementer. [M2.1] This stream is therefore not URI-addressable. However, it can be interleaved in the physical package using the same mechanisms used for interleaving parts.

9.1.2.2 Content Types Stream Markup

The Content Types stream identifies the content type for each package part. The Content Types stream contains XML with a top-level Types element, and one or more Default and Override child elements. Default elements define default mappings from the extensions of part names to content types. Override elements are used to specify content types on parts that are not covered by, or are not consistent with, the default mappings. Package producers can use pre-defined Default elements to reduce the number of Override elements on a part, but are not required to do so. [O2.4]

The package implementer shall require that the Content Types stream contain one of the following for every part in the package:

• One matching Default element
• One matching Override element
• Both a matching Default element and a matching Override element, in which case the Override element takes precedence. [M2.4]

The package implementer shall require that there not be more than one Default element for any given extension, and there not be more than one Override element for any given part name. [M2.5]

The order of Default and Override elements in the Content Types stream is not significant.

If the package is intended for streaming consumption:

• The package implementer should not allow Default elements; as a consequence, there should be one Override element for each part in the package.
• The format producer should write the Override elements to the package so they appear before the parts to which they correspond, or in close proximity to the part to which they correspond.

[S2.3]

The package implementer can define Default content type mappings even though no parts use them. [O2.5]

9.1.2.2.1 Types Element

The structure of a Types element is shown in the following diagram:

diagram
annotation	The root element of the Content Types stream.

9.1.2.2.2 Default Element

The structure of a Default element is shown in the following diagram:

diagram
attributes	Name Type Use Default Fixed Annotation Extension ST_Extension required A part name extension. A Default element matches any part whose name ends with a period followed by the value of this attribute. The package implementer shall require a non-empty extension in a Default element. [M2.6] ContentType ST_ContentType required A content type as defined in RFC 2616. Indicates the content type of any matching parts (unless overridden). The package implementer shall require a content type in a Default element and the format designer shall specify the content type. [M2.6]
annotation	Defines default mappings from the extensions of part names to content types.

9.1.2.2.3 Override Element

The structure of an Override element is shown in the following diagram:

diagram
attributes	Name Type Use Default Fixed Annotation ContentType ST_ContentType required A content type as defined in RFC 2616. Indicates the content type of the matching part. The package implementer shall require a content type and the format designer shall specify the content type in an Override element. [M2.7] PartName xs:anyURI required A part name. An Override element matches the part whose name is equal to the value of this attribute. The package implementer shall require a part name. [M2.7]
annotation	Specifies content types on parts that are not covered by, or are not consistent with, the default mappings.

9.1.2.2.4 Content Types Stream Markup Example

[Example:

Example 9--7. Content Types stream markup

<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>

The following is a sample list of parts and their corresponding content types as defined by the Content Types stream markup above.

end example]

9.1.2.3 Setting the Content Type of a Part

When adding a new part to a package, the package implementer shall ensure that a content type for that part is specified in the Content Types stream; the package implementer shall perform the following steps to do so [M2.8]:

1. Get the extension from the part name by taking the substring to the right of the rightmost occurrence of the dot character (.) from the rightmost segment.
2. If a part name has no extension, a corresponding Override element shall be added to the Content Types stream.
3. Compare the resulting extension with the values specified for the Extension attributes of the Default elements in the Content Types stream. The comparison shall be case-insensitive ASCII.
4. If there is a Default element with a matching Extension attribute, then the content type of the new part shall be compared with the value of the ContentType attribute. The comparison might be case-sensitive and include every character regardless of the role it plays in the content-type grammar of RFC 2616, or it might follow the grammar of RFC 2616.

1. If there is no Default element with a matching Extension attribute, a new Default element or Override element shall be added to the Content Types stream.

9.1.2.4 Getting the Content Type of a Part

To get the content type of a part, the package implementer shall perform the following steps [M2.9]:

1. Compare the part name with the values specified for the PartName attribute of the Override elements. The comparison shall be case-insensitive ASCII.
2. If there is an Override element with a matching PartName attribute, return the value of its ContentType attribute. No further action is required.
3. If there is no Override element with a matching PartName attribute, then

1. If there is a Default element with a matching Extension attribute, return the value of its ContentType attribute. No further action is required.
2. If neither Override nor Default elements with matching attributes are found for the specified part name, the implementation shall not map this part name to a part.

9.1.2.5 Support for Versioning and Extensibility

The package implementer shall not use the versioning and extensibility mechanisms defined in Part 5: "Markup Compatibility and Extensibility" to incorporate elements and attributes drawn from other XML-namespaces into the Content Types stream markup. [M2.10]