Open Packaging Conventions v0.85 Coming Changes

Here's the change summary for the upcoming version 0.85 of the Open Packaging Conventions:

General Changes

  • The former Appendix B on Markup Compatibility and Appendix J on the Markup Compatibility schema have been separated from this specification into its own Open XML Markup Compatibility specification.
  • All conformance requirements have been assigned a unique rule identifier in square brackets for purposes of conformance tool references.
  • A number of conformance requirements throughout the specification were not properly noted with conformance language (MUST, SHOULD, etc.); these have been updated.

Chapter 1. Package Model

  • Clarifications to part name syntax (1.1.1.1).
  • Added requirement that content types for package-specific parts MUST NOT have parameters (1.1.2).
  • Added the requirement: "If XML content contains the Markup Compatibility namespace, as described in the Markup Compatibility specification, it MUST be processed to remove Markup Compatibility elements and attributes and ignorable namespaces before applying further validation rules." (1.1.4)
  • Added the requirement: "XML content MUST be valid against the corresponding XSD schema defined in this specification. In particular, the XML content MUST NOT contain namespaces that are not explicitly defined in the corresponding XSD unless the XSD allows any namespace to be present in particular locations in the XML markup." (1.1.4)
  • Added the requirement: "XML content MUST NOT contain "xml" or "xsi" namespaces unless they are explicitly defined in the XSD schema or by other means in the specification." (1.1.4)
  • Added the requirement: "The XML 1.0 specification allows for the usage of Data Type Definitions (DTDs), which enable Denial of Service attacks, typically through the use of an internal entity expansion technique. As mitigation for this potential threat, DTD content MUST NOT be used in the XML markup defined in this specification, and consumers MUST treat the presence of DTD content as an error." (1.1.4)

Chapter 2. Physical Packages

  • Changed the requirement for interleaved parts to RECOMMEND one <Override> element per part rather than REQUIRE it (2.2.4).
  • Clarified the syntax of logical item naming (2.2.6.1).
  • Removed requirement for all logical item names with suffix names to belong to a complete sequence (2.2.6.1)
  • Added requirement: "Packages MUST NOT contain logical items with equivalent prefix names and with equal piece numbers, where piece numbers are treated as integer decimal values." (2.2.6.1)
  • Added requirement: "A logical item name or complete sequence of logical item names sharing a common prefix MUST NOT be mapped to a part name if the logical item prefix has no corresponding content type." (2.3.1.3)
  • Removed asterisk from note on ZIP item naming limitations, since this was not a legal part naming character (2.3.1.5).

Chapter 3. Package-Wide Features

  • Added requirement stated that applications must design signing/verification to allow for the possibility of different extended content, if an application allows such content (3.3.8.2).

Appendix B. Resolving Unicode Strings to Part Names

  • Conversion from URI to IRI, if necessary, must be done according to RFC 3987 (B.2).
  • Added clarification to remove trailing dot characters from each segment and to remove trailing forward slashes from the reference when resolving a relative reference to a part name (B.3).

Appendix C. Pack URI

  • Itemization of grammatical and syntactical terms defined by RFC 3986. Clarification of pack URI grammar defined in the Pack URI Scheme section of the appendix (C.1).
  • Clarified requirements around usage of the path component of a pack URI (C.1).

Appendix D. ZIP Appnote.txt Clarifications

  • Column "Pass through on editing" added to main table, "Support for records".
  • Yes/No values throughout the tables in this section were updated to accommodate the new column and closure on requirements.

Appendix I. Standard Namespaces and Content Types

  • Updated all namespaces, content types and relationship types per the editorial notes in the previous version of this specification.

Appendix J. Conformance Requirements

  • New appendix summarizing all conformance requirements from throughout this specification.

References

  • Updated reference for ABNF specification to RFC 4234 (was 2234).