Semi E138

SEMI E138 defines a library of common XML components — shared schema fragments for things like timestamps, equipment identifiers, unit-of-measure declarations, and status-code structures — that other XML-based SEMI standards (E128's XML message structures, E133.1's process-control messaging, E142.1's substrate-mapping schema, and more) reference and reuse rather than each redefining independently. Without a shared component library, every XML-based SEMI standard written over the years would face the same choice: either redefine its own notion of "timestamp" or "equipment ID" from scratch, or informally copy another standard's definition and hope it stays consistent as both evolve — and a fab integrating multiple XML-based standards would then have to reconcile subtly different representations of the same basic concept across every standard it implements.

Multiple XML-based SEMI standards each need timestamps, IDs, units, status codes
Without a shared library, each standard defines these independently
SEMI E138 — common XML component libraryShared schema fragments every other XML standard can reference
One canonical schema for timestamps, equipment IDs, units, status codes
Referenced, not reimplemented, by every standard that needs them
Versioned centrally — one place to update, not N independent copies
Consistency guaranteed by construction, not by convention
A fab integrating multiple XML-based standards parses one consistent representation
No reconciling subtly different timestamp/unit formats across standards

The reason this needed a dedicated standard rather than being left as an informal convention is that XML-based SEMI standards weren't all written at once by one team — they accumulated over years as different needs arose (equipment self-description, process-control messaging, substrate mapping), and without a formally shared component library, "informal convention" tends to drift: one standard's committee might define a timestamp as ISO 8601 with milliseconds, another as Unix epoch seconds, and a host trying to build one parsing layer across both inherits that inconsistency as integration work it shouldn't have had to do. E138 solves this the same way a shared code library solves duplicate-logic drift in software: by giving every XML-based SEMI standard a single, versioned, authoritative definition for the handful of concepts nearly all of them need, so consistency is structural rather than hoped-for.

The E138 Schema File Every Other XML Standard Imports one canonical definition instead of N independently-drifting copies E138-common.xsd <xs:complexType name="Timestamp"> <xs:element name="iso8601"/> </xs:complexType> <xs:complexType name="EquipID"> <xs:element name="value"/> </xs:complexType> + UnitOfMeasure, StatusCode — one place, versioned targetNamespace: semi.org/e138/v2 E128.xsd <xs:import ns="e138"/> E133.1.xsd <xs:import ns="e138"/> E142.1.xsd <xs:import ns="e138"/> any future .xsd <xs:import ns="e138"/> Update the Timestamp definition once in E138 — every importing standard inherits it, nothing redefined

E138 is what keeps every XML-based SEMI standard speaking the same basic language — by giving timestamps, equipment identifiers, units of measure, and status codes one canonical, versioned schema definition that every other XML standard references rather than redefines, it prevents the slow drift that would otherwise accumulate across a growing family of independently-authored standards, and saves a fab integrating several of them from having to reconcile incompatible representations of the same underlying concept.

Take SEMI E138 further

Ask the copilot about this term, or have our engineers assess it against your process.