Format, Schema, Profile, Encoding, and Extension: What a File Label Does—and Does Not—Tell You
“It is a STEP file” or “the receiver supports IFC” is not yet an exchange specification. A useful compatibility description identifies what the representation means, which scope of the standard is in use, how it is encoded, what it depends on, and which direction the receiving product supports.
The label is a routing hint
A filename extension helps software choose how to inspect a file. It usually does not tell you all of the following:
- which information model or representation family is inside;
- which schema release, application scope, profile, or model view applies;
- which optional extensions are used or required;
- whether the bytes are text, binary, or a container holding several parts;
- where external resources are located; or
- whether a particular product can read, write, translate, or use the result.
Those details are separate layers of the exchange contract. A receiver can recognize an extension and still lack the implementation or context needed to interpret the content usefully.
A practical vocabulary
The terms overlap in everyday conversation, so use them as questions about different layers:
| Term | What it identifies | Question to ask |
|---|---|---|
| Representation family | The broad kind of data being delivered, such as native authoring data, neutral product data, a scene asset, or a print-oriented model | What kind of information is this meant to carry? |
| Format | The defined organization and syntax for a representation | What rules describe the file or document? |
| Schema | The entities, properties, relationships, and constraints available in a model | Which data structures can appear? |
| Application protocol or application scope | A scoped selection of model concepts for a domain or use | Which part of a larger model is intended for this exchange? |
| Profile or model view | A constrained view of what a consumer is expected to provide or understand | Which subset or information requirement is in play? |
| Extension | An additional, named capability beyond a core representation | Which extra behavior or data is declared, and is it required? |
| Encoding | How the representation is serialized, such as JSON text or binary data | How are the model’s values represented as bytes? |
| Container or package | A physical wrapper that stores one or more related parts | Which files, relationships, and resources are inside this document? |
| File extension | A short suffix used for naming and routing | What should I inspect next? |
Not every representation uses every term. The point is to avoid treating one label as if it answered all of them.
Bounded examples
ISO describes ISO 10303 as a series with architectural parts that include data-specification methods, application protocols, implementation methods, conformance testing, and identification of schemas and other information objects. That overview explains why “STEP” is a family with scope choices, not a single promise about every product exchange. The public ISO page describes the 2024 edition’s architecture and lifecycle; it does not prove a product’s implementation or a route’s preservation result.
IFC gives a different, visible versioning example. buildingSMART lists IFC 4.3.2.0 as an official release, while IFC 4.4 and IFC 5 are shown as under development on the accessed release database. Its notation is Major.Minor.Addendum.Corrigendum, and the page assigns different compatibility implications to those components. A file named .ifc still needs its exact release and any applicable view or information requirement before a support claim becomes meaningful.
glTF shows why even two version labels can refer to different layers. A valid glTF asset declares asset.version; a Binary glTF (GLB) also has a container-header version. The specification says the GLB header version refers to the container and does not replace checking the asset version in the JSON chunk. A .glb suffix therefore identifies a container form, not the complete interpretation or destination behavior.
Record the exchange contract
Before sending or evaluating a file, request a record like this:
representation_family: "..."
format_or_standard: "..."
format_release: "..."
schema_application_scope: "..."
profile_or_model_view: "..."
extensions_used: []
extensions_required: []
encoding_and_container: "..."
external_resources: "none | listed separately | embedded and external"
direction: "read/import | write/export | direct open | reference"
source_product_and_release: "..."
destination_product_and_release: "..."
downstream_purpose: "..."
Use unknown when a field has not been established. An unknown field is a reason to investigate, not a reason to guess.
What to do next
Use scoped representations when a family label is known but the schema, profile, model view, or extension scope is not. Use directional and versioned support to interpret a product’s documentation, then use translation mechanics to understand why support does not by itself establish preservation.
Key points
- A file extension is a routing hint, not a compatibility verdict.
- Format, schema, scope, extension, encoding, container, and dependencies answer different questions.
- A standard can define a representation without proving product support or downstream usefulness.
- Record the exact scope and direction before comparing a source with a destination.