OpenEik.org

Errata of OpenEik 0.2. From commit 9077aa6c of 1 November 2026. Raw text: /errata/0.2.md. Errata of other versions: OpenEik 0.1, OpenEik 0.3, OpenEik 0.4.

On this page

OpenEik 0.2 specification

Errata of OpenEik 0.2

The errata of OpenEik 0.2, each with its number, the date it was accepted, the version it was found in, the passage as it was, the correction and the patch version that applies it (GOVERNANCE.md; Part I, 9.5).

0.2-E1: Part IV, 2 and Conformance, 1, the class-A rules of Part IV, 7.3 to 7.6 bound to no class

  • Accepted: 30 October 2026, by the steward (in the openEik.org thread: "allt ja enligt din rekommendation").
  • Found in: 0.2 as tagged v0.2.0.
  • As it was: Part IV, 2 said "A compiler of the core class MUST implement the class-A rules of sections 3 to 6 (4.6 and 4.7 among them), 11.2 and 12", and Conformance, 1 listed for the compiler (core) class Part IV, 1, 4, 5, 6, 12, 11.1, 11.2, 11.3 and 1.1. Yet Part IV, 7.3 (straight, L and U stairs), 7.4 (a framed wall layer's members, a roof's truss layout and its hip ends, and a floor's joists), 7.5 (a room's boundary, ceiling and quantities) and 7.6 (a component's frame and its bodies) are each part of 0.2 and say "These are class-A rules", so that they bound no class: the cut made the proposals of 0.1 rules of 0.2 and did not add their sections to the class. Part IV kept 0.1's account of what is reference behaviour around them: section 2's table, its last column headed "Status in 0.1", put room boundaries in class B and timber framing, trusses and stairs in class C, as reference behaviour; section 7 was headed "Reference behaviour (informative)", over 7.3 to 7.6 too; section 7.2 said that what it lists is "reference behaviour in 0.1", and named a door's and a window's own body without the frame, leaves and glass that section 4.3.1 of 0.2 gives it; section 7.4.2 said "the core compiler of 0.1 ends a wall square"; and the Terminology called reference behaviour what the reference implementation does "where 0.1 fixes no rule".
  • Correction: Part IV, 2 binds a compiler of the core class to the class-A rules of sections 3 to 6, 7.3 to 7.6, 11.2 and 12, and Conformance, 1 lists Part IV, 7.3 to 7.6 for the compiler (core) class. Section 2's table gives the status in 0.2: class A names the rules 0.2 adds, those of 7.3 to 7.6 among them, and classes B and C are reference behaviour but for those of 7.3 to 7.5, as section 7.2 says; a section part of 0.2 says what it is in a model of 0.1. Section 7 is headed "Reference behaviour, and the class-A rules stated from it", says that 7.1 and 7.2 are informative and that 7.3 to 7.6 state class-A rules, and 7.1 and 7.2 are headed so; section 7.2 lists reference behaviour without a version, a door's and a window's own body but for its frame, leaves and glass (4.3.1, of 0.2); section 7.4.2 says that a compiler of the core class ends a wall square, as in 0.1 (open questions, 104); and the Terminology says "where this specification fixes no rule". Conformance, 3 and open questions, section 2, rows 56 and 57, record where the reference implementation does not yet meet section 7.6 (question 99 (a) and (b)), as row 55 records 7.5. The rest of the version and its implementations show that this was meant: everything decided for 0.2 is a rule of it (decision D5, open questions, section 4); the compiler's core class is the one that implements the class-A rules (Terminology); Conformance, 3 already counted where the reference implementation differs from Part IV, 7.5 among what it does not yet meet of the compiler (core) class (row 55); and @openeik/tools, which claims that class of 0.2, derives them for every model of 0.2. Conformance, 1.1 names no section of Part IV, and is unchanged. No schema or example changes.
  • Applied by: 0.2.1, tagged v0.2.1.

0.2-E2: Part XIII, 10, the sources cited by buildingSMART's documentation

  • Accepted: 30 October 2026, by the steward (in the openEik.org thread: "allt ja enligt din rekommendation").
  • Found in: 0.2 as tagged v0.2.0.
  • As it was: as 0.2 took them from 0.1, before 0.1-E1 (errata/0.1.md): the sources of Part XIII, 10 (informative) cited IfcDistributionPort, IfcRelConnectsPorts, IfcElectricDistributionBoard, IfcDistributionBoard, IfcProtectiveDevice, IfcLightFixture, Pset_SwitchingDeviceTypeCommon, PEnum_SwitchFunctionType, Pset_ElectricalDeviceCommon, IfcCableSegment and IfcCableCarrierSegment by links into buildingSMART's source repository of IFC 4.3, IfcDistributionSystem and IfcDistributionCircuit by such a link beside their documentation, and the enumerations of IFC4 ADD2 TC1 by its reference EXPRESS file there.
  • Correction: the correction of 0.1-E1: each is cited by buildingSMART's documentation of IFC 4.3 (https://standards.buildingsmart.org/IFC/RELEASE/IFC4_3/HTML/lexical/<name>.htm), as the list already cited IfcDistributionSystem and IfcDistributionCircuit, and the enumerations by the EXPRESS schema of IFC4 ADD2 TC1 (https://standards.buildingsmart.org/IFC/RELEASE/IFC4/ADD2_TC1/EXPRESS/IFC4.exp). The working text has it since 30 October 2026 (4d25134c). Informative; no rule, schema or example changes.
  • Applied by: 0.2.1, tagged v0.2.1.

0.2-E3: Conformance, 1.1, Part XVIII's column holding the reference implementation's status

  • Accepted: 30 October 2026, by the steward (in the openEik.org thread: "allt ja enligt din rekommendation").
  • Found in: 0.2 as tagged v0.2.0.
  • As it was: in the table of Conformance, 1.1, where each part's column says what that part asks of each class, the column of Part XVIII held the reference implementation's status in five classes: in the reader's row, after "its files, as section 1 says", which records of 0.2 it reads and writes; and in the rows of the writer, the compiler (core), the command processor and the version store, which Part XVIII, 9 does not name, what it does not yet meet of 0.2 ("Of 0.2: …", "It implements none of Part XVII yet …", "Of Part XV: …"). Conformance, 3, where the reference implementation's status is, did not say these things in those classes' rows.
  • Correction: the column says what Part XVIII asks of each class, as its section 9 names them: of a reader, its files, as section 1 says, and nothing of a writer, a compiler, a command processor or a version store, as 1.1 says where a part names no requirement for a class. Each status sentence is at the end of its class's row in Conformance, 3, naming its row of open questions, section 2 (rows 39, 40, 42 to 49 and 52 to 55), which list each gap already. The working text has it since 30 October 2026 (4f101383). No rule, schema or example changes.
  • Applied by: 0.2.1, tagged v0.2.1.

0.2-E4: The schema of a view, the categories of 0.2 it may name

  • Accepted: 31 October 2026, by the steward (in the openEik.org thread: "allt ja enligt din rekommendation"). Found by the reference implementation's migration of every version of its projects to 0.2, in 14 of 121 versions.
  • Found in: 0.2 as tagged v0.2.0.
  • As it was: schemas/0.2/drawings/view.schema.json listed, in a view's hiddenCategories, visibility.categories and visibility.foregroundCategories and as the names of visibility.opacity, the 31 categories of 0.1 (Part II, 6.2) and none of the five 0.2 adds: member (Part II, 6.2.1), provision (Part II, 6.10), and electrical, cableCarrier and cable (Part XIII, 2, 5 and 6). So a validator refused a view of 0.2 that hid, showed or faded an element of one of those categories by its category, as a view does any other, though the index of 0.2 lists all 36 (schemas/0.2/index.json, categories). The cut made the proposals of 0.1 categories of 0.2 and did not add them to the view's lists. As tagged, the schemas of the commands create and type.upsert listed the 31 too, which is erratum 0.2-E5's.
  • Correction: each of the four lists names the 36 categories of 0.2, in the order the index of 0.2 lists them. A view's lists name categories, and every category of 0.2 is one; nothing the schema accepted before is refused. This changes what a tool that uses the schema accepts: a view that names one of the five is valid.
  • Applied by: 0.2.2, tagged v0.2.2.

0.2-E5: The schemas of the commands, the categories and kinds of 0.2

  • Accepted: 31 October 2026, by the steward (in the openEik.org thread: "ja till E5"). Found while erratum 0.2-E4 was applied to 0.2 as tagged: the commands' schemas it compared the view's lists with listed 0.1's categories at the tag, and 0.2's on main only since f32a1ba3 and 51d4a62f (30 October 2026), which made them 0.2's as implementations of its text.
  • Found in: 0.2 as tagged v0.2.0.
  • As it was: the schemas of the commands, schemas/0.2/commands/, were 0.1's under 0.2's addresses. create.schema.json and type.upsert.schema.json listed, as the category of the element or the type they carry, the 31 categories of 0.1 and none of the five 0.2 adds (member, provision, electrical, cableCarrier and cable), and held none of them to its category's schema. index.json listed the core record operations alone: not view.upsert, which Part V, 2.2 lists, nor the three kinds Part XIII, 9 adds, circuit.upsert, circuit.delete and view.lighting, and there was no schema of any of the four. So a validator that held a command on a model of 0.2 to the schemas of 0.2 refused a create of a member, a provision, a device, a carrier or a cable, and every view.upsert, circuit.upsert, circuit.delete and view.lighting, which the text of 0.2 defines. The cut made the proposals of 0.1 categories and kinds of 0.2 and did not fold them into the commands' schemas.
  • Correction: the commands' schemas are those main has since f32a1ba3 and 51d4a62f: create and type.upsert name the 36 categories of 0.2, in the order the index of 0.2 lists them, and hold each element and type to its category's schema; index.json lists view.upsert and Part XIII, 9's three kinds with their preconditions, each held to its schema, view.upsert.schema.json, circuit.upsert.schema.json, circuit.delete.schema.json and view.lighting.schema.json. Nothing the schemas accepted before is refused. This changes what a tool that uses the schemas accepts: a command that the text of 0.2 defines is valid.
  • Applied by: 0.2.3, tagged v0.2.3.