1. Introduction

ISO 10303 is an international standard for the computer-interpretable representation of product information and the exchange of product data. Commonly known as STEP (Standard for the Exchange of Product Model Data), the standard uses the EXPRESS data modeling language to define product information schemas. The traditional implementation method is Part 21 (the clear-text file format with .stp and .ifc extensions). This article introduces a new experimental JSON encoding as an alternative approach, designed to be more accessible, easier to process with modern web technologies, and more developer-friendly while maintaining full compatibility with the underlying EXPRESS data model.

2. The Standard Part 21 File Format

The most commonly used ISO 10303 EXPRESS data encoding is ISO 10303 Part 21. According to the specification document IS_final_p21e3.pdf, the exchange structure consists of three main components:

  1. Header Section - Contains metadata about the file, including description, filename, and schema

  2. Data Section - Contains the actual entity instances with their attributes

  3. Trailer - Marks the end of the document

The primary use cases for ISO 10303 Part 21 include:

  1. Data archival

  2. Data exchange between different CAD and PLM systems

Part 21 offers several advantages:

  1. Human readability - The clear-text format allows engineers to inspect and understand the data structure

  2. Compactness - Efficient encoding that doesn’t require excessive storage

  3. Wide adoption - Supported by virtually all CAD and PLM software worldwide

A complete Part 21 EXPRESS data document has the following highly structured format:

ISO-10303-21;
HEADER;
FILE_DESCRIPTION(('ViewDefinition [DesignTransferView]'),'2;1');
FILE_NAME('ifc-mini','2026-03-10T15:40:47',(' ','[email protected]'),
('Procedural Information System, LLC'),'1.0','PIComposer','Procedural Information System, LLC');
FILE_SCHEMA(('IFC4x3'));
ENDSEC;

DATA;
#2=IFCORGANIZATION($,'Procedural Information System, LLC',$,$,$);
#1=IFCPERSON($,' ','[email protected]',$,$,$,$,$);
#25=IFCPROJECT('cdkVRiz-T626rvNum8e6ZQ',#5,'ifc-mini',$,$,$,$,(#11),#24);
...
ENDSEC;
END-ISO-10303-21;

Each entity instance in the Data section follows the pattern #ID=ENTITY_TYPE(attribute1, attribute2, …​); where:

  1. #ID is a unique numeric identifier for the entity

  2. ENTITY_TYPE is the EXPRESS entity name (e.g., IFCPROJECT, IFCAXIS2PLACEMENT3D)

  3. The attributes are enclosed in parentheses and can include references to other entities by their ID (e.g., #5)

3. Common File Extensions: STP and IFC

Two file extensions are commonly associated with Part 21 format files:

stp files - Used for STEP files across various application protocols (APs), including:

  • AP203 - Configuration controlled 3D design of mechanical parts and assemblies

  • AP210 - Electronic assembly, interconnect, and packaging design

  • AP214 - Automotive mechanical design processes

  • AP238 - Integrated CNC (Computer Numerical Control) machining

  • AP242 - Managed model-based 3D engineering (the convergence of AP203 and AP214)

ifc files - Used specifically for Industry Foundation Classes (IFC) files in building information modeling (BIM)

While all these formats use the same Part 21 encoding, they adhere to different EXPRESS schemas tailored to specific domains. The schema is declared in the FILE_SCHEMA header entity:

IFC4x3 - Building construction and facility management (BIM)

AUTOMOTIVE_DESIGN - Automotive design (AP214)

CONFIG_CONTROL_DESIGN - Configuration-controlled design (AP203)

MODEL_BASED_3D_ENGINEERING - Managed model-based engineering (AP242)

This domain-specific specialization allows each application protocol to define precisely the entities, attributes, and relationships needed for its particular use case while sharing a common file format foundation.

4. The New JSON Encoding Format

This new experimental encoding represents EXPRESS data using JSON (JavaScript Object Notation). The JSON encoding maintains the same semantic content as Part 21 but presents it in a format that is:

  1. Easier to parse - Native support in virtually every programming language

  2. Web-friendly - Ideal for web-based applications and APIs

  3. Developer-friendly - Familiar JSON syntax with clear structure

  4. Interoperable - Works seamlessly with modern data processing tools

The ISO 10303-11:2004 standard (available as iso-10303-11-2004.pdf) defines the EXPRESS modeling language that both formats represent.

4.1. Basic Structure

The JSON encoding has the following structure:

{
"ISO-10303-20": [
{
"HEADER": [
["FILE_DESCRIPTION", ["ViewDefinition [DesignTransferView]"], "2;1"],
["FILE_NAME", "ifc-mini", "2026-03-10T15:40:47", [" ", "[email protected]"],
["Procedural Information System, LLC"], "1.0", "PIComposer", "Procedural Information System, LLC"],
["FILE_SCHEMA", ["IFC4x3"]]
]
},
{
"DATA": [
[2, "IFCORGANIZATION", null, "Procedural Information System, LLC", null, null, null],
[1, "IFCPERSON", null, " ", "[email protected]", null, null, null, null]
]
}
]
}

The JSON object contains an "ISO-10303-20" property with two main sections:

  1. HEADER - An array of header entity definitions containing file metadata

  2. DATA - An array of entity instances representing the product data

4.2. Header Section

The HEADER section is an array where each element represents a header entity. Each header entity is an array containing:

  1. The entity type name (e.g., FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA)

  2. The entity attributes as separate array elements

["FILE_DESCRIPTION", ["ViewDefinition [DesignTransferView]"], "2;1"]
["FILE_NAME", "ifc-mini", "2026-03-10T15:40:47", [" ", "[email protected]"],
["Procedural Information System, LLC"], "1.0", "PIComposer", "Procedural Information System, LLC"]
["FILE_SCHEMA", ["IFC4x3"]]

4.3. Data Section

The DATA section contains entity instances as JSON arrays. Each entity instance follows this pattern:

[instance_id, "ENTITY_TYPE", attribute1, attribute2, ...]

For example, comparing Part 21 to JSON:

Part 21 Format
#2=IFCORGANIZATION($,'Procedural Information System, LLC',$,$,$);
JSON Format
[2, "IFCORGANIZATION", null, "Procedural Information System, LLC", null, null, null]

The mapping is straightforward:

  1. #2 becomes the first element: 2

  2. IFCORGANIZATION becomes the second element: "IFCORGANIZATION"

  3. Each attribute in parentheses becomes a subsequent element in the array

  4. The $ (undefined) marker in Part 21 becomes null in JSON

4.4. Entity References

In EXPRESS data models, entities frequently reference one another to build complex relationships—for example, a project contains units, a unit assignment references unit definitions, a geometric context references a coordinate system, and so on. Part 21 represents these references using instance IDs (e.g., #5).

4.4.1. Basic Entity References

The entity reference uses just the target instance ID:

Part 21 Format
#5=IFCOWNERHISTORY(#4,#3,.READWRITE.,...,1773157247);
#25=IFCPROJECT('cdkVRiz-T626rvNum8e6ZQ',#5,'ifc-mini',...);
JSON Format
[5, "IFCOWNERHISTORY", 4, 3, ".READWRITE.", ..., 1773157247],
[25, "IFCPROJECT", "cdkVRiz-T626rvNum8e6ZQ", 5, "ifc-mini", ...]

In this example, the IFCPROJECT instance references IFCOWNERHISTORY instance #5 simply by including the ID 5 as the attribute value.

4.5. Select Type Handling

The EXPRESS SELECT type defines a union of possible types—similar to a discriminated union in modern programming languages. An instance of a SELECT type can hold a value of any one of the types specified in its select list. The JSON encoding represents SELECT instances using a simple, consistent pattern: ["TYPE", value], where "TYPE" identifies the specific type from the select list, and value is the encoded instance of that type.

Consider this EXPRESS schema fragment:

ENTITY IfcProperty
ABSTRACT SUPERTYPE OF (ONEOF
(IfcComplexProperty
,IfcSimpleProperty))
SUBTYPE OF (IfcPropertyAbstraction);
Name : IfcIdentifier;
Specification : OPTIONAL IfcText;
END_ENTITY;

ENTITY IfcSimpleProperty
ABSTRACT SUPERTYPE OF (ONEOF
(...
,IfcPropertySingleValue
,IfcPropertyTableValue))
SUBTYPE OF (IfcProperty);
END_ENTITY;

ENTITY IfcPropertySingleValue
SUBTYPE OF (IfcSimpleProperty);
NominalValue : OPTIONAL IfcValue;
Unit : OPTIONAL IfcUnit;
END_ENTITY;

TYPE IfcValue = SELECT
(IfcDerivedMeasureValue
,IfcMeasureValue
,IfcSimpleValue);
END_TYPE;

TYPE IfcMeasureValue = SELECT
(...
,IfcPlaneAngleMeasure
...);
END_TYPE;

TYPE IfcPlaneAngleMeasure = REAL;
END_TYPE;

TYPE IfcAxis2Placement = SELECT
(IfcAxis2Placement2D
,IfcAxis2Placement3D);
END_TYPE;

ENTITY IfcRepresentationContext
ABSTRACT SUPERTYPE OF (ONEOF(IfcGeometricRepresentationContext));
ContextIdentifier : OPTIONAL IfcLabel;
ContextType : OPTIONAL IfcLabel;
END_ENTITY;

ENTITY IfcGeometricRepresentationContext
SUBTYPE OF (IfcRepresentationContext);
CoordinateSpaceDimension : IfcDimensionCount;
Precision : OPTIONAL IfcReal;
WorldCoordinateSystem : IfcAxis2Placement;
TrueNorth : OPTIONAL IfcDirection;
END_ENTITY;

The JSON encoding applies the ["TYPE", value] pattern recursively to handle nested SELECT types:

[6, "IFCAXIS2PLACEMENT3D", 7, 8, 9],
[11, "IFCGEOMETRICREPRESENTATIONCONTEXT", null, "Model", 3, 0.00001, ["IFCAXIS2PLACEMENT3D", 6], 10],
[63, "IFCPROPERTYSINGLEVALUE", "Roll", null, ["IFCMEASUREVALUE", ["IFCPLANEANGLEMEASURE", 0.0]], null]

Let’s examine how the SELECT types resolve in these examples:

  1. In instance #11, the WorldCoordinateSystem attribute expects an IfcAxis2Placement (a SELECT type). The value ["IFCAXIS2PLACEMENT3D", 6] indicates that this instance uses IfcAxis2Placement3D (a concrete type from the select list) and refers to entity #6 for its value.

  2. In instance #63, the NominalValue attribute expects an IfcValue (a SELECT type). The value ["IFCMEASUREVALUE", ["IFCPLANEANGLEMEASURE", 0.0]] shows two levels of nesting:

    1. The outer ["IFCMEASUREVALUE", …​] selects IfcMeasureValue from the IfcValue select list

    2. The inner ["IFCPLANEANGLEMEASURE", 0.0] selects IfcPlaneAngleMeasure from the IfcMeasureValue select list and provides the actual value 0.0

For comparison, here is how the same instances are encoded in Part 21:

#6=IFCAXIS2PLACEMENT3D(#7,#8,#9);
#11=IFCGEOMETRICREPRESENTATIONCONTEXT($,'Model',3,1.E-05,#6,#10);
#63=IFCPROPERTYSINGLEVALUE('Roll',$,IFCPLANEANGLEMEASURE(0.),$);

The Part 21 encoding handles SELECT types through complex context-sensitive rules, requiring the parser to know which types are valid in each position. The JSON encoding’s explicit typing makes parsing simpler and more robust—the type information is always immediately available, eliminating ambiguity.

This consistent ["TYPE", value] pattern applies to all SELECT types, including nested SELECTs, nested aggregates containing SELECTs, and SELECTs used in aggregates or entity attributes. The same pattern works regardless of the depth of nesting, making the encoding predictable and easy to process programmatically.

4.6. Complete Example: IFC-MINI

The following example shows the complete JSON encoding of a simple IFC model:

{
"ISO-10303-20": [
{
"HEADER": [
["FILE_DESCRIPTION", ["ViewDefinition [DesignTransferView]"], "2;1"],
["FILE_NAME", "ifc-mini", "2026-03-10T15:40:47", [" ", "[email protected]"],
["Procedural Information System, LLC"], "1.0", "PIComposer", "Procedural Information System, LLC"],
["FILE_SCHEMA", ["IFC4x3"]]
]
},
{
"DATA": [
[2, "IFCORGANIZATION", null, "Procedural Information System, LLC", null, null, null],
[1, "IFCPERSON", null, " ", "[email protected]", null, null, null, null],
[12, "IFCGEOMETRICREPRESENTATIONSUBCONTEXT", "Body", "Model", "", "", "", "", [11, "IFCGEOMETRICREPRESENTATIONCONTEXT"], null, ".MODEL_VIEW.", null],
[13, "IFCGEOMETRICREPRESENTATIONSUBCONTEXT", "FootPrint", "Model", "", "", "", "", [11, "IFCGEOMETRICREPRESENTATIONCONTEXT"], null, ".MODEL_VIEW.", null],
[14, "IFCGEOMETRICREPRESENTATIONSUBCONTEXT", "Axis", "Model", "", "", "", "", [11, "IFCGEOMETRICREPRESENTATIONCONTEXT"], null, ".MODEL_VIEW.", null],
[4, "IFCPERSONANDORGANIZATION", 1, 2, null],
[3, "IFCAPPLICATION", 2, "1.0", "PIComposer", "PIC"],
[5, "IFCOWNERHISTORY", 4, 3, ".READWRITE.", null, null, null, 1773157247],
[6, "IFCAXIS2PLACEMENT3D", 7, 8, 9],
[7, "IFCCARTESIANPOINT", [0.0, 0.0, 0.0]],
[8, "IFCDIRECTION", [0.0, 0.0, 1.0]],
[9, "IFCDIRECTION", [1.0, 0.0, 0.0]],
[10, "IFCDIRECTION", [0.0, 1.0]],
[11, "IFCGEOMETRICREPRESENTATIONCONTEXT", null, "Model", 3, 0.00001, 6, 10],
[15, "IFCSIUNIT", "", ".LENGTHUNIT.", ".MILLI.", ".METRE."],
[16, "IFCSIUNIT", "", ".PLANEANGLEUNIT.", null, ".RADIAN."],
[17, "IFCSIUNIT", "", ".AREAUNIT.", null, ".SQUARE_METRE."],
[18, "IFCSIUNIT", "", ".VOLUMEUNIT.", null, ".CUBIC_METRE."],
[19, "IFCSIUNIT", "", ".MASSUNIT.", ".KILO.", ".GRAM."],
[20, "IFCSIUNIT", "", ".TIMEUNIT.", null, ".SECOND."],
[21, "IFCSIUNIT", "", ".SOLIDANGLEUNIT.", null, ".STERADIAN."],
[22, "IFCSIUNIT", "", ".THERMODYNAMICTEMPERATUREUNIT.", null, ".DEGREE_CELSIUS."],
[23, "IFCSIUNIT", "*", ".LUMINOUSINTENSITYUNIT.", null, ".LUMEN."],
[24, "IFCUNITASSIGNMENT", [
["IFCSIUNIT", 15], ["IFCSIUNIT", 16], ["IFCSIUNIT", 17], ["IFCSIUNIT", 18],
["IFCSIUNIT", 19], ["IFCSIUNIT", 20], ["IFCSIUNIT", 21], ["IFCSIUNIT", 22], [ "IFCSIUNIT", 23]
]],
[25, "IFCPROJECT", "cdkVRiz-T626rvNum8e6ZQ", 5, "ifc-mini", null, null, null, [11], 24]
]
}
]
}

4.7. Complete Example: AP214 (Automotive Design)

The following example demonstrates the JSON encoding for an automotive design schema (AP214):

{
"ISO-10303-20": [
{
"HEADER": [
["FILE_DESCRIPTION", ["PIComposer model"], "2;1"],
["FILE_NAME", "mini-ap214", "2026-03-09T19:18:36", [" ", "[email protected]"],
["Procedural Information System, LLC"], "1.0", "PIComposer", "Procedural Information System, LLC"],
["FILE_SCHEMA", ["AUTOMOTIVE_DESIGN"]]
]
},
{
"DATA": [
[2, "APPLICATION_PROTOCOL_DEFINITION", "design", "AUTOMOTIVE_DESIGN", 2007, [1, "APPLICATION_CONTEXT"]],
[1, "APPLICATION_CONTEXT", "Core data for automotive mechanical design processes"],
[4, "PRODUCT_DEFINITION_CONTEXT", "3D Mechanical Parts", [1, "APPLICATION_CONTEXT"], "design"],
[3, "PRODUCT_CONTEXT", "3D Mechanical Parts", [1, "APPLICATION_CONTEXT"], "Mechanical"],
[5, ["LENGTH_UNIT"], ["NAMED_UNIT", ""], ["SI_UNIT", ".MILLI.", ".METRE."]],
[6, ["NAMED_UNIT", ""], ["PLANE_ANGLE_UNIT"], ["SI_UNIT", null, ".RADIAN."]],
[7, ["NAMED_UNIT", "*"], ["SI_UNIT", null, ".STERADIAN."], ["SOLID_ANGLE_UNIT"]],
[9, "UNCERTAINTY_MEASURE_WITH_UNIT", ["LENGTH_MEASURE", 1e-7], ["NAMED_UNIT", 5],
"DISTANCE_ACCURACY_VALUE", "Maximum model space distance between geometric entities at asserted connectivities"],
[8, ["GEOMETRIC_REPRESENTATION_CONTEXT", 3], ["GLOBAL_UNCERTAINTY_ASSIGNED_CONTEXT", [9]],
["GLOBAL_UNIT_ASSIGNED_CONTEXT", [["NAMED_UNIT", 5], ["NAMED_UNIT", 6], ["NAMED_UNIT", 7]]],
["REPRESENTATION_CONTEXT", "YbMw-sZ_ReGEm5z7kCL06Q", "3D"]]
]
}
]
}

5. Mapping Between Formats

The following table summarizes the key mappings between Part 21 and the JSON encoding:

Aspect Part 21 Format JSON Format

Document Start

ISO-10303-21;

"ISO-10303-20": […​]

Header Section

HEADER; …​ ENDSEC;

"HEADER": […​]

Data Section

DATA; …​ ENDSEC;

"DATA": […​]

Instance ID

#2=

First array element: 2

Entity Type

IFCORGANIZATION

Second element: "IFCORGANIZATION"

Undefined ($)

$

null

Derived (*)

*

*

Entity Reference

#7

7

String Value

'text'

"text"

Binary

hexadecimal string

Base64 string

Enumeration Value

.MODEL_VIEW.

".MODEL_VIEW."

List/Set

(item1, item2)

[item1, item2]

Document End

END-ISO-10303-21;

(end of JSON object)

6. Flexibility and Extensibility

The JSON encoding format is designed to be highly flexible and extensible, making it fully capable of representing everything defined in the ISO 10303 Part 21 specification. While Part 21 uses a fixed syntax with specific delimiters and keywords, JSON provides a more flexible container that can adapt to any EXPRESS data structure.

6.1. As Powerful as Part 21

The JSON format is not a simplified subset of Part 21—it is a complete representation that can encode all the same information:

  1. Full header support - All header entities (FILE_DESCRIPTION, FILE_NAME, FILE_SCHEMA) are fully supported

  2. Complete entity instances - Every entity type, including complex nested structures, can be represented

  3. All data types - INTEGER, REAL, STRING, BOOLEAN, LOGICAL, ENUMERATION, BINARY, SELECT, and ENTITY references are all natively supported

  4. List and set constructs - JSON arrays naturally represent EXPRESS lists and sets

  5. Optional attributes - JSON’s null value perfectly represents undefined ($) attributes

  6. Complex expressions - Binary data, nested lists, and derived attributes can all be encoded

  7. Entity references - References maintain full type information for unambiguous parsing

6.2. Extensibility Features

The JSON format offers additional extensibility that Part 21 cannot provide:

  1. Custom metadata - Additional metadata can be added without affecting parsers

  2. Schema annotations - Information about the underlying EXPRESS schema can be embedded

  3. Compression ready - Natural fit for gzip or other compression algorithms

  4. Streaming capable - Can be processed incrementally for very large files

  5. Version information - Easy to include version and transformation metadata

  6. Queryable - Can be queried with tools like JSONPath or JMESPath

This extensibility allows the JSON format to serve not only as a direct replacement for Part 21 but also as a foundation for extended capabilities such as incremental updates, partial loading, and cloud-optimized representations.

7. Support for Advanced Part 21 Features

The JSON encoding fully supports features defined in ISO 10303-21 Edition 3, including anchor sections, signature sections and other advanced features.

7.1. Anchor Section

Anchors provide stable, human-readable identifiers for entities, values, or resources within an exchange structure. These anchors can be referenced externally, enabling distributed models and persistent identification that survives instance ID renumbering.

Part 21 Format
ANCHOR;
<POINT_1> = #1;
<POINT_2> = #2;
<PI_VALUE> = 3.14159;
<MESSAGE> = 'Hello World';
<EXTERNAL_REF> = http://example.com/library.json#MyAnchor;
<TAGGED_ITEM> = #10 [status:approved] [version:2.3];
ENDSEC;
JSON Format (Map/Object)
{
"ISO-10303-20": [
{
"HEADER": [...]
},
{
"ANCHOR": {
"POINT_1": 1,
"POINT_2": 1,
"PI_VALUE": 3.14159,
"MESSAGE": "Hello World",
"EXTERNAL_REF": { "$ref": "http://example.com/library.json#MyAnchor" },
"TAGGED_ITEM": {
"target": 10,
"tags": {
"status": "approved",
"version": 2.3
}
}
}
},
{
"DATA": [...]
}
]
}

7.2. Anchor Value Types

The anchor map supports the same value types as the rest of the JSON encoding:

Anchor Type

JSON Representation

Example

Entity reference

Integer ID

"POINT_1": 1

Simple value

Number, string, boolean

"PI_VALUE": 3.14159

Resource reference

{"$ref": "uri"}

"EXTERNAL_REF": {"$ref": "lib.json#Anchor"}

List/Set

JSON array

"COORDINATES": [1.0, 2.0, 3.0]

Tagged item

Object with target and tags

See example above

7.3. Tagged Anchors

Part 21 allows anchors to have tags—additional metadata outside the EXPRESS schema. In the JSON encoding, these are naturally represented as a tags object within the anchor entry:

"ANCHOR": {
"WELD_EDGE": {
"target": 20,
"tags": {
"preparation": "WELD_DC.XML",
"inspection": "ISO-5817-B",
"priority": "high"
}
},
"BEAM_PROFILE": {
"target": ["IFCPROFILE", 42],
"tags": {
"source": "catalog.xls#H-BEAM",
"units": "mm"
}
}
}

7.4. UUID-Based Anchors

For globally unique identifiers, UUIDs can be used as anchor names:

"ANCHOR": {
"3f2504e0-4f89-11d3-9a0c-0305e82c3301": 25,
"9a7c8b6d-2e45-4f89-8a3b-c1d4e5f67890": ["IFCPRODUCT", 42],
"f81d4fae-7dec-11d0-a765-00a0c91e6bf6": {
"target": 17,
"tags": {
"author": "buildingSMART",
"version": "IFC4x3"
}
}
}

7.5. Benefits of Map Representation

Using a JSON map for the anchor section provides several advantages:

  1. Direct lookup - Consumers can access an anchor by name in O(1) time: data.ANCHOR.POINT_1

  2. Cleaner syntax - Eliminates repetitive array entries and makes the name-value relationship explicit

  3. Natural tagging - Tags become nested objects, which is much cleaner than the Part 21 bracket syntax

  4. Extensibility - New anchor types can be added without changing the overall structure

  5. Schema validation - JSON Schema can validate anchor names against patterns (e.g., UUID format)

  6. Compatibility - This pattern matches how anchors work in other web formats (JSON-LD, OpenAPI)

7.5.1. Signature Section

Digital signatures ensure data authenticity and integrity:

Part 21 Format
SIGNATURE;
MIIGpY3KoZ1hvNCAQcCoIIG1zCCBpMCAQExCzA3BgluDgMCGgUAMAaGCSqGSIb3
DQEHAAcCA9cwggPTMIICu6ADAgECAgEEmABGCSqGSIb3DQEBcUAMhOxEzARBgoJ
ENDSEC;
JSON Format
{
"ISO-10303-20": [
{
"HEADER": [...]
},
{
"DATA": [...]
},
{
"SIGNATURE": "MIIGpY3KoZ1hvNCAQcCoIIG1zCCBpMCAQExCzA3BgluDgMCGgUAMAaGCSqGSIb3DQEHAAcCA9cwggPTMIICu6ADAgECAgEEmABGCSqGSIb3DQEBcUAMhOxEzARBgoJ..."
}
]
}

This comprehensive support ensures that any valid Part 21 file—from simple single-section exchanges to complex distributed models with signatures and anchors—can be faithfully represented in the JSON encoding without loss of information or functionality.

8. Advantages of the JSON Format

  1. Ecosystem compatibility - JSON is the de facto standard for data interchange in web and cloud applications

  2. Tooling support - Extensive tooling for validation, transformation, and processing

  3. Streaming support - Can be processed as a stream for large files

  4. Schema validation - Easy to validate against JSON Schema

  5. API integration - Ready for REST API integration without conversion

  6. Modern development - Perfect for JavaScript, Python, and other modern programming languages

  7. Flexibility - More adaptable to modern application requirements

  8. Extensibility - Can be extended without breaking existing parsers

  9. Readability - Familiar syntax for developers worldwide

  10. Debugging - Easy to inspect and debug with standard tools

9. Conclusion

This experimental JSON encoding provides a modern, accessible alternative to the traditional Part 21 format while maintaining full semantic equivalence. It bridges the gap between the established STEP/EXPRESS ecosystem and modern web-based development practices.

Most importantly, it is not a simplified alternative—it is a fully capable encoding that can represent everything defined in the ISO 10303 Part 21 specification, with additional flexibility and extensibility for modern application needs.

The JSON encoding is particularly valuable for:

  1. Web-based CAD applications

  2. Cloud-based data processing pipelines

  3. Integration with modern APIs and services

  4. Development and debugging workflows

  5. Machine learning and data analysis applications

  6. Real-time collaboration tools

Both the Part 21 format (with .stp and .ifc extensions) and this new JSON format represent the same underlying EXPRESS data model defined by ISO 10303-11:2004. The choice between formats depends on your specific use case, tooling requirements, and integration needs.

We welcome feedback and collaboration from the community to further refine this encoding and ensure it meets the needs of the STEP/EXPRESS user community.

10. References

  1. ISO 10303-11:2004 - Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual

  2. ISO 10303-21 - Industrial automation systems and integration — Product data representation and exchange — Part 21: Implementation methods: Clear text encoding of the exchange structure

  3. IFC (Industry Foundation Classes) - buildingSMART International

  4. STEP (Standard for the Exchange of Product Model Data) - ISO 10303

  5. RFC 8259 - The JavaScript Object Notation (JSON) Data Interchange Format

11. Appendix: Example Files

The following example files are provided with this article: