One File, Many Forms: Containers, Packages, and External Resources

“Send the file” is not a complete delivery instruction. A representation may be a text document, a binary encoding, a container with embedded parts, or an entry point into a larger set of referenced resources. The receiver needs to know which form is present and how its dependencies will be resolved.

Separate the physical layers

These layers can coincide, but they do not automatically do so. One file can still point outside itself; a package can contain data that a receiver does not understand; and an extension can identify a container form without proving package closure.

glTF: JSON, resources, and GLB

The glTF 2.0 specification describes a JSON .gltf file containing a scene description, with binary .bin files and image files as possible resources. Binary and image resources may instead be embedded through Data URIs or stored in a GLB container.

GLB is a binary container with a 12-byte header and JSON and binary chunks. Its JSON chunk may reference resources stored in other chunks or external resources. The specification therefore makes an important distinction: a .glb extension tells you that the Binary glTF container form is being used; it does not prove that every image, buffer, or other dependency is embedded.

Before delivering glTF, inspect the resource references and decide which of these states applies:

• all required resources are embedded;
• resources are included as separate files with portable relative references; or
• resources remain external and require a documented resolver or environment.

Also inspect extensionsUsed and extensionsRequired. The latter is the subset of used extensions required to load or render the asset. A declaration helps the receiver decide what it must support, but it does not prove that the receiver implements the extension.

USD: layers and composition are part of interpretation

OpenUSD organizes data in Layers and uses composition arcs to assemble a resolved Stage. subLayers form an ordered, nestable LayerStack. references compose a prim tree from another layer into a referencing prim. payload arcs defer references that can be loaded or unloaded, and VariantSets provide selectable variations in stronger layers.

This is more than a list of files. The composition rules determine what the receiver sees after resolution. OpenUSD also documents asset paths and a resolver that can be customized per installation or plugin package. The same recorded path may therefore depend on the receiving environment’s naming, versioning, or resolver policy.

OpenUSD lists usda as a text format, usdc as a binary format, and usdz as a packaged archive format through USD file-format plugins. Those forms do not by themselves establish that a particular application includes, resolves, flattens, or preserves every composed asset. Confirm the actual package and resolver behavior for the application and delivery environment.

3MF: a package with explicit relationships

The 3MF Consortium publishes a Core Specification and purpose-specific extensions. Its suite page lists the core’s ISO/IEC 25422 value as v1.3.0 and a separate latest-revision PDF value as v1.4.0. The package rules below are specifically from the directly retrieved Core Specification v1.3.0; do not silently apply them to later revisions without checking the exact document.

Core v1.3.0 defines a 3MF Document as an XML-based model and containing format built on the Open Packaging Conventions and physically realized as a ZIP archive. A 3D payload is a complete collection of interdependent parts and relationships. The StartPart relationship identifies the root of the primary 3D payload.

The same specification says content used to manufacture an object must be contained in the document and that a 3MF document must not reference resources outside the package unless an extension specifies otherwise. A required extension cannot simply be ignored by an unsupported consumer: the consumer must fail to edit or manufacture the document. The model also declares units, resources, and build items, and a MustPreserve relationship can tell a consumer to retain an associated custom part when modifying the package.

These rules describe the 3MF representation contract. They do not prove that a receiver supports a particular extension, that a package was produced correctly, or that the resulting build is acceptable.

Build a representation manifest

Attach a small manifest to the handoff or record it in the exchange request:

primary_file: "..."
format_and_version: "..."
schema_profile_or_extensions: []
encoding_and_container: "..."
entry_point_or_start_part: "..."
included_parts:
  - "..."
external_resources:
  - path_or_uri: "..."
    required_for: "..."
    resolution_environment: "..."
units_and_coordinates: "..."
intended_operation: "..."
receiver_support_reference: "..."
acceptance_check: "..."

The manifest is a delivery aid, not proof of completeness. Test the package in an environment that matches the receiver’s real working conditions.

Know which category owns the next question

Product structure and references owns assembly and dependency completeness. Visual scenes and assets owns visual-resource survival. Validation and long-term reuse owns controlled acceptance, reproducibility, and retrieval. This category identifies representation conditions so those checks can be designed with the right scope.

Key points

• Extension, encoding, container, and logical package are different layers.
• A GLB or archive may still have external or unresolved dependencies.
• USD composition and resolver behavior can change what a receiver resolves.
• Package rules and extension declarations describe obligations, not actual receiver support or acceptance.