Information layer / category
Formats, Profiles, and Translators
A filename is only the start of an interoperability question. This category explains how representation families, schemas, profiles, extensions, encodings, containers, versions, and translator implementations affect the information a receiver can interpret.
Overview
Use these articles before treating a support-table entry or file extension as a compatibility conclusion. First identify the representation and the job it must support. Then identify the precise scope inside that representation, confirm the direction and release of the product support, and account for the mapping work a translator performs.
The category also covers a common source of failed handoffs: a file can be syntactically valid while its external resources, layers, or package relationships are unavailable to the receiver. Representation mechanics help you ask what must travel with the primary file; they do not replace validation of assembly dependencies, visual assets, or acceptance criteria.
Articles
Read the articles in this order:
- Format, schema, profile, encoding, and extension defines the identifiers hidden behind a file label.
- Native, neutral, and derived representations compares representation families by the next job and the information that must survive.
- Schemas, application protocols, model views, and extensions explains the scope inside a nominally familiar format.
- Read, write, import, and export shows how to interpret directional, release-bound support statements.
- What a CAD translator actually has to do describes implemented mapping and its possible limits.
- Containers, packages, and external resources helps determine whether “send the file” is enough.
What this category does not establish
The existence of a format or profile does not prove that a particular application implements it, that a translator preserves a specific information layer, or that a received result is useful for the downstream task. Use geometry and topology, product structure and references, editability, and the portal’s validation content for those questions.
Reference notes
Articles in this layer
Format, Schema, Profile, Encoding, and Extension: What a File Label Does—and Does Not—Tell You
A file extension cannot identify the complete exchange contract. Learn which representation, scope, version, encoding, and dependency details to record before judging compatibility.
Native, Neutral, and Derived Representations: Choose for the Next Job
Choose a native, neutral, or derived representation by the information and downstream task that matter—not by file-extension popularity.
Schemas, Application Protocols, Model Views, and Extensions: The Scope Inside the Format
A familiar format name can contain several scopes. Learn how schemas, application protocols, model views, profiles, and extensions change what a receiver must understand.
Read, Write, Import, Export: Why Support Is Directional and Version-Bound
Interpret format-support statements by operation, product release, representation scope, and documented limitations before relying on an import or export.
What a CAD Translator Actually Has to Do
Opening a file is an implemented mapping between representations. Learn where scope, fallback, transformation, and validation decisions can change the result.
One File, Many Forms: Containers, Packages, and External Resources
A standalone file, an encoded container, and a resource-bearing package are different things. Learn what to identify before assuming a transfer is self-contained.
Sources
- ISO 10303-1:2024 primary
- IFC Schema Specifications primary