Aspect
Section: 3.9 Extensibility and profile composition
Orientation relevance: both
The general method has to let specific industries add their own extra items without breaking the shared approach, and let profiles build on one another rather than starting from a blank page. This issue is about how those add-ons and combinations work.
Example
Telecoms uses cryptography that other industries don't — for example, special mobile-network algorithms. Rather than copy and fork the whole method, telecoms should be able to add those as an "extension" on top of a base profile, much like bolting a specialist module onto a standard course. That makes "procurement profile + telecom extension" a valid, tidy combination.
Objective
Decide how sectors and organisations extend the methodology without forking it, and whether
profiles can derive from or compose with one another.
Background & links
Scoping document §3.9. The telecommunications case (air-interface algorithms, interface
"reference points") is the worked example of a sector extension; see the GSMA telecom CBOM work
for a concrete instance. Namespacing ties back to identity (3.2).
Options under consideration
- Inheritance + composition — a profile may derive from a single base profile and compose
with extensions (e.g. procurement profile + telecom extension). (Trade-off: powerful; needs
clear precedence/merge rules.)
- Flat profiles + referenced overlays — no inheritance; sector specifics live in separate
referenced overlay profiles. (Trade-off: simpler; more duplication.)
Open questions
Dependencies
Depends on attribute model (3.3 #1) and identity/namespacing (3.2 #5).
Decision
Not yet decided.
Impact on the specification
Spec section "Extensibility and profile composition."
Aspect
Section: 3.9 Extensibility and profile composition
Orientation relevance: both
The general method has to let specific industries add their own extra items without breaking the shared approach, and let profiles build on one another rather than starting from a blank page. This issue is about how those add-ons and combinations work.
Example
Telecoms uses cryptography that other industries don't — for example, special mobile-network algorithms. Rather than copy and fork the whole method, telecoms should be able to add those as an "extension" on top of a base profile, much like bolting a specialist module onto a standard course. That makes "procurement profile + telecom extension" a valid, tidy combination.
Objective
Decide how sectors and organisations extend the methodology without forking it, and whether
profiles can derive from or compose with one another.
Background & links
Scoping document §3.9. The telecommunications case (air-interface algorithms, interface
"reference points") is the worked example of a sector extension; see the GSMA telecom CBOM work
for a concrete instance. Namespacing ties back to identity (3.2).
Options under consideration
with extensions (e.g. procurement profile + telecom extension). (Trade-off: powerful; needs
clear precedence/merge rules.)
referenced overlay profiles. (Trade-off: simpler; more duplication.)
Open questions
Dependencies
Depends on attribute model (3.3 #1) and identity/namespacing (3.2 #5).
Decision
Not yet decided.
Impact on the specification
Spec section "Extensibility and profile composition."