Schemas, Application Protocols, Model Views, and Extensions: The Scope Inside the Format
“Supports IFC,” “opens STEP,” or “loads glTF” describes a family label. A useful exchange statement identifies the particular scope inside that family and what happens when the receiver encounters information outside it.
One family can contain several contracts
Separate these questions:
- Schema: Which entities, properties, relationships, and constraints exist?
- Application protocol or domain scope: Which subset of a larger model is assembled for a particular application area?
- Profile or model view: Which constrained view or information requirement is expected by a consumer?
- Extension: Which additional capability is present beyond the core representation?
- Status and release: Is this scope official, withdrawn, retired, under development, or tied to a particular version?
The names are not interchangeable. A product can support one release or view and not another. A file can declare an extension that the receiver does not implement. A specification can define all of them without proving that a product maps them correctly.
STEP: architecture is not a route
The public ISO 10303-1:2024 overview describes architectural principles for the ISO 10303 series and lists application protocols, implementation methods, conformance-testing concepts, and schema identification among its scope. This is enough to establish that the series has more structure than a single “STEP” label.
It is not enough to infer a product route. The overview does not tell you which application protocol a particular exporter writes, which implementation method a receiver uses, or which product data survives the mapping. Those are product- and route-specific questions.
IFC: release and view context matter
The buildingSMART IFC release database lists IFC 4.3.2.0 as an official release. On the accessed page, IFC 4.4 and IFC 5 are marked as under development, while other entries are marked official, withdrawn, or retired. Treat those status values as part of the representation record; do not turn a development entry into a compatibility recommendation.
The page expresses IFC versions as Major.Minor.Addendum.Corrigendum. Its explanation says major changes may break compatibility; minor versions extend features with compatibility guaranteed for the core schema but not other definitions; addendums improve existing features with upward compatibility guaranteed; and corrigendums improve documentation, although deprecation may be possible. These are release-notation statements, not application support guarantees.
When an IFC workflow relies on a particular view or information requirement, record it alongside the release and schema. The schema tells you what the model can express; the selected view or requirement helps define what the receiving workflow expects. Confirm that the sender and receiver use the same interpretation before treating a schema match as sufficient.
Extensions: used is not always required
glTF makes extension scope explicit. The specification requires every extension used by an asset to appear in the top-level extensionsUsed array. Extensions required to load or render the asset must also appear in extensionsRequired, and extensionsRequired is a subset of extensionsUsed.
That distinction creates two different receiver questions:
- Does the receiver recognize an extension that may improve or add information?
- Does the receiver support an extension required to load or render the asset?
The declaration improves the receiver’s ability to make a compatibility decision. It does not prove the receiver implements the extension or preserves its information after translation.
3MF provides another bounded example. Its Core Specification v1.3.0 defines core and extension versions independently through XML namespaces. It also allows a producer to mark an extension as required; a consumer that does not support a required extension must fail to edit or manufacture the document rather than silently ignore it. The exact behavior belongs to that specification version and extension scope.
A sender-and-receiver checklist
Ask for these values before a transfer:
| Check | Sender should identify | Receiver should confirm |
|---|---|---|
| Core representation | Format, schema, or family | The exact supported scope |
| Release and status | Version and whether it is official, development, withdrawn, or retired | Supported release and any conversion rule |
| Application scope | AP, domain scope, profile, model view, or information requirement | The view or subset the workflow consumes |
| Extensions | Used, required, and their versions where applicable | Supported, ignored, rejected, or mapped behavior |
| Encoding/container | Text or binary form and package type | Reader and parser support |
| Fallback | What may be omitted or represented differently | Whether the workflow can proceed safely with that result |
| Purpose | The operation the receiver must perform | Acceptance checks for that operation |
Use an explicit unknown rather than assuming the broadest scope. If a required extension or view is not supported, a cleanly opened file may still be unsuitable for the intended task.
Follow the implementation question
Directional and versioned support shows how to read a product support declaration. Translation mechanics explains why a declared scope still has to be mapped into the destination’s data model. For information-layer acceptance, continue to the portal categories on geometry, structure, and engineering semantics.
Key points
- A format family can contain multiple schema, release, view, profile, and extension scopes.
- Official status does not prove product support; product support does not prove preservation.
- Required extensions demand a different receiver response from optional or merely used extensions.
- Record exact scope, status, extensions, fallback behavior, and intended purpose.