A
Resource/Service Catalog is an entity, of which there may be many, containing an array of
Categories.
Categories are entities containing an array of
Candidates which reference a specific
Specification. So to understand what is "made available" by a
Catalog it is necessary to navigate the relationships.
I understand that most people view a
"Service Catalog" as being the REST Collection returned from
GET /serviceCatalogManagement/v4/serviceSpecification
however that is not what TMF633 tell us. So go ahead and ignore
Catalog,
Category and
Candidate for your purposes but their use remains valid.
The question about versions is an interesting one. I can see the logic in the
id
attribute remaining the same while the
version
increments however the implication is that there is only one version available. It seems equally valid to retain the old entity and create a new one, requiring a new
id
. But what is the implication on the reference? In the first case there is only one entity available so at best
version
in the reference is a validity check. In the second case since
id
is a mandatory attribute
version
isn't performing a discrimination between available entities of different versions.
I would suggest that if and when this issue is addressed a solution should support
Semantic Versioning. If
serviceSpecification.version: 4.1.32
then a reference with
serviceCandidate.serviceSpecification.version: 4.1
would match but
serviceCandidate.serviceSpecification.version: 4.1.29
would not.
------------------------------
Vance Shipley
SigScale
------------------------------
------------------------------