“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
| Layer | Meaning | Example question |
|---|---|---|
| File extension | A name suffix used for routing or recognition | Is this .gltf, .glb, .usd, .usdz, or .3mf? |
| Encoding | How model data is serialized into bytes | Is the representation JSON text, binary, XML, or another encoding? |
| Container | A physical wrapper holding one or more chunks or parts | Which parts and relationships are inside this blob or archive? |
| Logical package | The complete set of files and dependencies needed for the intended use | What must be delivered and resolved for the scene, model, or build to work? |
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.
For package-specific checks on the USDZ entry layer, alignment, path resolution, and inspection tools, see USDZ package layout and resolver constraints.
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.
PCB fabrication illustrates a multi-file handoff
A fabrication handoff may include separate Gerber layer images, a Gerber Job File JSON document, and drill/rout data. The job schema describes job-level values such as material stackup, design rules, and attributes for files; it is not the geometry in the layer images and does not establish that referenced files are present or match the selected board.
Ucamco lists XNC Revision 2021.11 separately from the Gerber layer and Job File documents. Its specification describes drill/rout exchange between PCB CAD and CAM; it does not describe a direct machine-ready output. A separate structured option is ODB++Design: the cited Release 8.1 Update 3 specification describes a directory-based product model with step-level EDA data and a required UNITS directive. That cited revision is dated February 2021; it is not asserted to be the latest ODB++ revision.
These examples show why a directory, ZIP, or “one package” label is not a completeness check. Identify the expected files or model tree, revisions, units and coordinate context, required attributes, and the receiver’s accepted input. See PCB fabrication representation choices for the comparison and request record.
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.