Open Packaging Conventions Specification (Open Packaging Conventions (OPC) specification)

Open Packaging Conventions Fundamentals

Introduces the OPC concepts that is required for using packaging APIs.

This topic contains the following sections.

• Introduction
• What is the Open Packaging Conventions (OPC)?
• Packages
  • Logical Model
  • Physical Model
  • Existing zip-based Package Formats
• Parts
• Relationships
  • Storing Relationships:relationships Parts
• Digital Signatures
• Related Topics

Introduction

the ECMA-376 OpenXML, 1st Edition, part 2:open Packaging Conventions (OPC) can is more easily understood through An analogy with real–world filing systems. People and businesses need to organize their information. Often, this information was tracked by using paperwork that's stored in folders, which am in turn, stored in filing cabin Ets. For the person and business, someone had to design a system to fit their needs, a system, the would allow information to be accessed as needed.

A Personalized Filing system provides great advantages when used by someone who understands how the system works and when Someone new needs to access the system, how does they know where to find the information they need? Suddenly, the personalized filing system becomes less convenient. Applications face similar challenges in organizing data:what information are most important and how can developers ensure That's it is easily accessible?

The OPC specification provides an answer to this question. A package, as described in the OPC, enables different applications to access key information from an opc–based fi Le in a standardized and predictable. A package was like a filing cabinet whose basic organization are known to all the people and businesses that interact with I T.

What is the Open Packaging Conventions (OPC)?

The Open Packaging Conventions (OPC) describes a new file technology that's documented in the ISO/IEC 29500 and ECMA 376 standards. Rather than a specific file format, OPC is a file technology for designing file formats with a shared, base Archi Tecture.

The OPC integrates elements of Zip, XML, and the WEB technologies into a open, industry standard that makes it E Asier to organize, store, and transport application data.

OPC is the file technology base for many new formats supported by Microsoft products and a growing number of othe R new Microsoft and Third-party applications. While these formats share OPC as a foundation, the data contained in a package file depends on the specific forma T.

Packages

A Aggregate of data components, like the filing cabinet (which are shown in the following illustration) are an Aggregate of an individual or business ' s paperwork.

Unlike Real–world filing systems, packages must conform to a predictable, conceptual organizational system (called the log ical model), and predicatable physical characteristics (called the physical model). These standardized conformance requirements is described in the OPC.

Logical Model

The logical model describes a package as an aggregate of data structured as a directed graph. A generic directed graph is shown in the following diagram.

The vertices of a package graph is all uri-addressable resources, and the edges is links between those resources. The links of a package graph is relationships. In a package graph, the both resources connected by a relationship is known as the source and target of the relationship; In a generic graph, these would is known as the initial and terminal vertices, respectively.

The resource is a source must being either the package itself or a data component (called a part) inside of the package. The target resource of a relationship can be any uri-addressable resource inside or outside of the package.

This model provides a format-independent the structuring and accessing package data.

Physical Model

While the logical model describes the data structure of a package in the abstract, the physical model maps those Logica L concepts to a physical format. The result of this mapping are a physical package format. For example, the OPC provides a mapping of the package concepts to the ZIP archive format; Parts is treated as file items and appear in a Directory-like hierarchy, is derived from part names. The result of this mapping are the physical, zip-based package format. To view the physical organization of any zip-based package, append the. ZIP extension to the package file name and open th E archive using Windows Explorer or a ZIP utility. The following screen shot illustrates a XPS file that is opened for browsing:

Any individual or organization can design a physical package format by mapping logical package concepts to a desired physi Cal format. As a result, package format designers can design and optimize a physical format for the specific needs of an application W Ithout compromising the logical structure of the package.

Currently, nearly all package formats is based on ZIP archives.

Existing zip-based Package Formats

Examples of zip-based package formats include:

• The OpenXML formats used in the Microsoft Office system:
  • Office Word documents (. docx)
  • Office Excel Worksheets (. xlsx)
  • Office PowerPoint presentations (. pptx)
• XPS documents (. xps)

Parts

In the analogy of a package to a real–world filing system, the parts in a package is like the folders in a filing cabinet . Parts Store application data, like folders (which is shown in the following illustration) store personal or business info Rmation.

To further extend the analogy, the content of a part was data in the form of a byte stream like the content of a folder is Information in the form of paperwork, as shown in the following illustration.

In the logical model of a, parts is resources that is uri-addressable data components inside a package. A part consists of a byte stream of data and properties. The properties is specified in the  OPC . The part's content Type property is uses a Mime-style media type to describe part content. The content types for parts is identified in a package-specific stream, called the content types stream. This stream contains XML markup, that maps parts, and extensions to content types. This XML markup are specified by the package format Designer or in the  OPC .

Parts also has the part name Property:the URI of the part, relative to the root of the package. However, the part name depends on the physical mapping of the package format and, therefore, cannot is predicted reliably From the one package, format to another. A part, exists in more than one package format is not with the same part name in different package files. To find the current part name of a part in the regardless of the package format, identify a relationship That targets, the part, and the relationship to resolve, the current part name.

For more information about parts and about finding their current part names, see the parts overview and the finding the Co Re Properties part how-to topic.

Relationships

In the analogy of a package to a real–world filing system, relationships can is used to navigate a package like Informatio N on a directory card can is used to navigate a filing system.

In the logical model of a, relationships is the links that connect a source to a target. While the source was either the package or a part, the target can being any uri-addressable resource inside or outside of the Package.

If the relationship target is inside the package, the targeted resource are a part of the package. If the target is outside of the package, the targeted resource can be any uri-addressable resource.

Only kinds of resources can is the source of a relationship:the package itself and a. If the source is the package, the relationship is called a package relationship; If the source is a part, the relationship are called a part relationship.

The relationship ' s properties provide access to the type of the relationship (the relationship type), Target mode, and the Relative URI of its target. The relationship type describes the connection between the relationship source and target. Relationship types is specified by the package format Designer or in the OPC. The target mode of a relationship indicates whether its target was inside or outside of the package; If inside, the target is a part. The relative URI of a relationship target uses the URI of the source as its base.

If the target of a relationship is a part, the relative URI of the "target" can be resolved to its part name. For the example, see Resolving a part Name from a Target URI. The resolution of a part name from the URI of a relationship ' s target was not contingent on the physical mapping of the PAC Kage.

Relationships is serialized by using specialized XML markup, called relationship markup. An example of a serialized relationship are shown in the following markup.

Xml

<relationship id= "rId1"    type= "http://schemas.openxmlformats.org/officeDocument/2006/relationships/ Officedocument "    target=" Word/document.xml "/>

Storing Relationships:relationships Parts

Relationships is stored in a specialized part, called a relationships part. There is one relationships part for each distinct relationship source in a package. All relationships the same source is stored in the same relationships part.

The part name of a relationships part was derived from the source URI of the the relationships. The. Content of a relationships part was the relationship markup, which is the serialized form of the stored Relationsh Ips.

Digital Signatures

In a package, a digital signature (signature) can is validated, confirming that the signed contents of the the package has no T been modified since the signature was generated.

ImportantAlthough signatures can used to validate the identity of the package signer and originator, this must is performed by T He package consumer.

A Package Signature can reference package, which has been signed. These components include XML markup, which has been signed in application-specific Object elements. The signature can also include certificates (or links to them) and which may is used in signature validation.

A package can has more than than one signature, and each signature can reference any package component or application-specific The content in a Object element that exists inside the signature markup.

The following table describes common package signature concepts.

Signature Concepts	Description
Signature	A Package digital signature. A digital signature generated for a package.
Reference to a part	A reference to one part of the has been signed.
Reference to Relationships	A reference to one or more relationships that has been signed and that is all stored in the same relationships part.
Reference to Application Data	A reference to application-specific data, have been signed and is contained in a specified object.
Object that contains application data	An Application-specific object, that contains application data, the May was signed when the signature was generated. This object is serialized as a element in the signature markup.
Certificate	An of certificate that was included when the signature was created and can be used in signature validation.

For more information on digital signatures, see the recommendation XML Signature Syntax and processing (HTTP://GO.MI crosoft.com/fwlink/p/?linkid=132847).

Related Topics

Packaging API Programming Guide

Overviews

Getting Started with the packaging API

External

ECMA-376 OpenXML

Open Packaging Conventions Specification (Open Packaging Conventions (OPC) specification)