What a CAD Translator Actually Has to Do

A translator is not a file-extension renamer. It must interpret one representation and produce a result in a different model, often with different validity rules, supported entities, units, attributes, and editing concepts.

Four claims that must stay separate

When evaluating a transfer, distinguish:

1. Specification capability: the standard or format defines a concept.
2. Support declaration: a product says it can read, write, open, or reference a scope.
3. Observed preservation: a controlled test shows which information arrived and how it is represented.
4. Task acceptance: the received result passes the checks required for the next operation.

Each claim is stronger and narrower than the previous one. A specification cannot certify a product mapping. A support table cannot prove that a source’s features or attributes survive. A visually plausible result cannot prove that it is suitable for editing, inspection, machining, or archiving.

A conceptual translation path

Implementations differ, but a useful mental model is:

recognize and decode
        ↓
interpret the declared scope and dependencies
        ↓
map source concepts into a destination model
        ↓
apply conversion, fallback, or repair policies
        ↓
serialize, reference, or package the result
        ↓
validate the result against the next operation

At each stage, information can be preserved, transformed, approximated, omitted, or represented through a different mechanism. Some choices are documented; others are implementation details that should be treated as unknown until observed.

Recognize and decode

The reader identifies the physical form, parses its syntax, and loads the bytes or package parts. A successful parse establishes that the input is readable at that layer. It does not establish that the full intended payload is present or that the destination understands every declared extension or resource.

Interpret scope and dependencies

The translator must know which schema, application protocol, profile, model view, extension, version, and external resources apply. A USD stage, for example, can compose layers and references and can defer payloads. A glTF asset can point to external binary or image resources. The translator’s result depends on what it can resolve and support in the current environment.

Map into a destination model

The destination model may not have a one-to-one equivalent for every source entity. A translator may create an intermediate or internal model, preserve only selected attributes, flatten relationships, approximate geometry, or omit unsupported information. The receiving model’s concepts and validity criteria matter as much as the source representation.

Apply policies and serialize

Settings can affect units, tolerances, write modes, shape processing, tessellation, attribute handling, or package structure. A result that is valid for one destination operation can be unsuitable for another. If defaults or fallback rules are undocumented, describe them as unknown rather than inventing a universal behavior.

A bounded implementation example: Open CASCADE Technology

Open CASCADE Technology (OCCT) documents Data Exchange interfaces that can query and examine an input, convert its contents into a CAD model, and run validity checks on the fully translated shape. It separately describes Extended Data Exchange (XDE) for attributes attached to geometry, including colors, layers, names, and materials. These are capabilities of the documented OCCT implementation, not a universal translator contract.

Its Shape Healing documentation distinguishes several effects. Analysis can detect violations without modifying the shape. Fixing may modify, remove, or create sub-shapes. Upgrade replaces a representation while remaining geometrically equivalent in the documented sense. Customization changes the mathematical form of an internal representation without modifying the shape. These distinctions matter because “healed” does not automatically mean “identical to source” or “accepted for the next task.”

IGES shows direction and scope in practice

OCCT’s IGES guide documents a read sequence of loading the file, optionally checking consistency, setting translation parameters, translating the file, and fetching results. It says the reader recognizes IGES 5.3 definitions but translates only 3D geometric entities; unhandled data is ignored and identified by a message. The guide also documents conversion of non-millimeter length values to millimeters on read, optional translation of Directory Entry attributes such as layers, colors, and thickness through XDE, and non-translation of administrative Global Section data such as file name, author, and creation or modification dates.

The write path has its own sequence: initialize the process, set translation parameters, translate the model, and write the output. OCCT documents separate write modes that affect whether faces are written as lower-level geometric entities or B-Rep entities. The read and write paths therefore must not be treated as reciprocal promises.

Evaluate the result at the data layer

After translation, check the properties that the downstream operation needs:

These checks belong to the downstream purpose, not merely to the fact that a translator returned without an error.

Handoff to route and recovery decisions

Use directional support to establish what the product documentation actually claims. Use containers and resources to identify what the translator must resolve. For failures, continue to the portal’s transfer recovery content; for layer-specific acceptance, use the relevant categories for geometry, structure, editability, semantics, and validation.

Key points

• Translation is an implemented mapping into a destination model.
• Parsing, product support, observed preservation, and task acceptance are different claims.
• Direction, settings, versions, scope, dependencies, and destination validity rules affect the result.
• A bounded implementation example can explain mechanisms without becoming a universal translator rule.