2 Conformance§
AGREED Profile names and the reconstruction requirement are stable. The test suite of Annex A is normative as to what must be tested; fixtures are not yet published.
2.1 Requirement keywords§
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.
NOTE In this draft the keywords are printed in a distinguishing color as an aid to review. Color carries no meaning; capitalization does.
2.2 Conformance targets§
| Target | What it is | How it is tested |
|---|---|---|
| Package | A single artifact. | Statically, with neither system present. Annex A group PK. |
| Exporter | A system that produces packages. | By the packages it produces, and by whether the owner can produce one unaided. Group EX. |
| Importer | A system that consumes packages. | By what it retains, what it refuses, and what it reports. Group IM. |
| Round-trip | An exporter and importer as a pair. | Export, import, re-export, compare in canonical form. Group RT. |
A system that both imports and exports MUST be evaluated as all three, and in round-trip against itself. Round-trip against itself is the weakest of the four and MUST NOT be reported alone.
2.3 Conformance profiles§
| Profile | Token | Domains |
|---|---|---|
| Core | core | identity, spaces, assets, points, relationships, resources, provenance |
| Core with intent | core-intent | core plus operational intent, alarms, and events |
| Core with intent and knowledge | core-intent-knowledge | the above plus human knowledge |
| Full | full | the above plus portable presentation and time-series history |
v0.2 normatively defines core, core-intent, and core-intent-knowledge. An implementation MAY claim full for presentation only if it also declares timeSeries as absent with a reason of deferredToLaterVersion; the time-series domain is not specified in this version and cannot be tested.
Property definitions are not a domain. They are infrastructure required of every profile by 7.8, and a package at any profile that emits a property without its definition is invalid.
Profiles are floors, not ceilings. An implementation claiming core MAY carry presentation, and SHOULD do so; it simply does not have its presentation handling tested.
2.4 The reconstruction requirement§
- Self-sufficiency. Every reference MUST resolve within the package, or MUST be a durable external locator with a digest (16.5). A reference only the exporting system can dereference does not satisfy this requirement, whatever its syntax. Test EX-1.
- Symmetry. An exporter MUST NOT omit any construct that the exporting system itself relies upon to operate the building, unless the omission is declared under 16.6. Test EX-4.
- Preservation over comprehension. An importer MUST preserve what it does not understand. Understanding is optional; retention is not. Tests RT-6, RT-7, RT-12.
For presentation specifically, reconstruction has a stronger practical test: an owner-role user MUST be able to export a floor plan and an equipment graphic, with geometry, element identity, and bindings intact, without vendor assistance (test EX-6). That test exists because the rebuild cost of graphics is the largest single line item in a real migration.
2.5 Claiming conformance§
An implementation claiming conformance MUST publish a conformance statement giving the targets and profiles claimed, the document and schema versions, the result of every applicable test in Annex A including tests not passed, every extension namespace it emits with its must-understand flag, and the substrate domains it cannot carry with the reason codes it will emit.
A conformance statement that reports only passes is not a conformance statement. An owner reading it MUST be able to determine, before purchase, what the product can and cannot preserve.