Aspect
Section: 3.2 Profile identity & metadata
Orientation relevance: both
Every profile needs a name, a version number, and a few basic facts about it, who maintains it,
and whether it is a draft, published, or retired. Without these, people can't refer to a profile
precisely in a contract or a tool. This issue is used to agree what identifying information every profile
must carry.
Example
Just as you'd cite "ISO 9001:2015" rather than "that quality standard," a buyer should be able to
write "requires the Telecom Procurement Profile v1.2" in a tender and have everyone know exactly
what is meant — including that v1.3 later added a requirement and v1.1 is now retired.
Objective
Decide how profiles are named, identified, versioned, and described, so they are
unambiguously referenceable in contracts, tools, and regulatory documents.
Background & links
Scoping document §3.2. Identifier and namespacing choices here are reused by extensibility
(3.9) and overlap with governance/versioning (3.11). Prior art worth reviewing: Package URL
(purl) identifier conventions; SemVer.
Options under consideration
- Namespaced identifier — reverse-DNS style (e.g.
org.pkic.cbom.profile.procurement) so
sector and organisation profiles cannot collide. (Trade-off: verbose; collision-safe.)
- Registry-assigned short ID + human name — central allocation. (Trade-off: needs a
registry; clean references.)
- Versioning — SemVer with defined breaking-change criteria, versus date-based versioning.
Open questions
Dependencies
Namespacing is reused by extensibility (3.9 #9); versioning/status coordinates with
governance (3.11 #11).
Decision
Not yet decided.
Impact on the specification
Spec section "Profile identity and metadata."
Aspect
Section: 3.2 Profile identity & metadata
Orientation relevance: both
Every profile needs a name, a version number, and a few basic facts about it, who maintains it,
and whether it is a draft, published, or retired. Without these, people can't refer to a profile
precisely in a contract or a tool. This issue is used to agree what identifying information every profile
must carry.
Example
Just as you'd cite "ISO 9001:2015" rather than "that quality standard," a buyer should be able to
write "requires the Telecom Procurement Profile v1.2" in a tender and have everyone know exactly
what is meant — including that v1.3 later added a requirement and v1.1 is now retired.
Objective
Decide how profiles are named, identified, versioned, and described, so they are
unambiguously referenceable in contracts, tools, and regulatory documents.
Background & links
Scoping document §3.2. Identifier and namespacing choices here are reused by extensibility
(3.9) and overlap with governance/versioning (3.11). Prior art worth reviewing: Package URL
(purl) identifier conventions; SemVer.
Options under consideration
org.pkic.cbom.profile.procurement) sosector and organisation profiles cannot collide. (Trade-off: verbose; collision-safe.)
registry; clean references.)
Open questions
Dependencies
Namespacing is reused by extensibility (3.9 #9); versioning/status coordinates with
governance (3.11 #11).
Decision
Not yet decided.
Impact on the specification
Spec section "Profile identity and metadata."