15 Extensions§

AGREED

15.1 Purpose§

The extension mechanism exists so that innovation does not wait for a version of this document, and so that a vendor is never forced to choose between conformance and a capability. It is also the mechanism most likely to be abused, and this clause is correspondingly strict.

15.2 Namespaces§

Extension data is carried in an extensions map whose keys are absolute URIs or reverse-DNS tokens. The prefix bus is reserved and MUST NOT be redefined.

15.3 Declaration§

Every namespace used anywhere in a package MUST be declared in the manifest with a prefix, a namespace URI, a must-understand flag, and SHOULD carry a description and specification URI. An undeclared namespace is a package validity failure (test PK-9). The rule exists so an owner can read one file and see every proprietary construct their building has accumulated.

15.4 Must-understand and preservation§

mustUnderstand SHOULD be set only where acting on the model without interpreting the extension would be wrong — a safety interlock expressed in a proprietary form, for example. Setting it routinely, so that no competitor can claim a clean import, is an abuse of the mechanism and governance should treat it as a conformance matter rather than a technical one.

15.5 Promotion§

An extension implemented by several independent parties, that expresses something about the building rather than about a product, is a candidate for promotion into the core in a later MINOR version. On promotion the core construct becomes normative and the extension namespace is deprecated but MUST continue to be accepted.

The same mechanism applies to property definitions (7.8.1), and is the route by which shared vocabulary is expected to emerge without a committee defining one in advance.