Annex A (informative). Relationship to Open Packaging Conventions
AFDS specification, version 1.0.0
Open Packaging Conventions, standardised as ECMA-376 Part 2 and ISO/IEC 29500-2, is a formal ZIP-based multi-part container.
An OPC package holds parts, each with a name and a content type.
Content types are declared in a [Content_Types].xml part at the package root, either by file extension default or by explicit override.
Relationships between parts are declared in separate XML relationship parts under _rels directories, so that a consumer discovers the package's structure by walking relationships from a package-level root rather than by convention.
OOXML uses this machinery to collect the many related parts of one document (the document body, styles, numbering definitions, embedded images, themes, and so on) into a single logical file, and other formats reuse it: ECMA-388 states that the OpenXPS format requirements "are an extension of the packaging requirements described in the Open Packaging Conventions (OPC) Standard".
AFDS borrows the principle and rejects the machinery.
A.1 What AFDS takes from OPC
The useful idea is that a package is one logical object made of related parts.
A consumer receives one file, can identify it, and can enumerate its contents without hunting through a folder tree.
That is exactly the problem the .afds container solves, and OPC demonstrates that a ZIP archive is a sound basis for it.
A.2 What AFDS rejects and why
| OPC mechanism | AFDS position | Reason |
|---|---|---|
| XML parts as the content model | Rejected | AFDS content is JSON and Markdown centred. Wrapping JSON in XML parts adds a representation nobody needs. |
[Content_Types].xml | Rejected | The inventory already carries a media type per entry, in the same file that carries the digest. |
_rels relationship parts | Rejected | The manifest already supplies the relationship map, in one place, in the format the rest of the package uses. |
| Part-naming grammar | Rejected | Normalised relative ZIP paths are sufficient and are what ordinary tools already show. |
| Relationship-walking discovery | Rejected | A consumer reads two known root files. Discovery by convention is simpler and easier to verify. |
| Single logical object made of related parts | Adopted | This is the principle worth keeping. |
The cost of the rejection is real and worth stating. AFDS gains no benefit from existing OPC tooling, and a developer who already knows OPC must learn a second set of conventions. The judgement is that OPC's XML parts and relationship model add complexity without improving a JSON and Markdown centred representation, and that a manifest a person can read in a text editor is worth more to this project than reuse of an XML relationship library.