Hi
@Jonathan Goldberg, thanks for your attention and reply.
Yes. We're making extensive use of the @type in our implementations to especialize or enrich
out-of-the box resources provided in these APIs.
I'm also in contact with Kamal to discuss details around these Open APIs which we're implementing right
now in our products so that his help in conjunction with the answers I get here are indeed makes the
difference.
Hi
@Vance Shipley.
Your information around planned changes over the API endpoints along next release of TMF634 is indeed
what I was looking for. With that, I see a better alignment between TMF633 & TMF634 structures.
Many thanks.
Regards,
------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------
Original Message:
Sent: Apr 03, 2020 03:59
From: Vance Shipley
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones
Marcos asks: "Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?"
You can, and we do. Both LogicalResourceSpecification and PhysicalResourceSpecification are subtypes of ResourceSpecification.
I suspect what you are looking at is how the URIs are provided in the 17.0 version of TMF634 where we see:
/catalogManagement/resourceSpec/
/catalogManagement/logicalResourceSpec/
/catalogManagement/physicalResourceSpec/
You won't find that in the new releases of TMF634 where we have a consistent use of:
/resourceCatalogManagement/resourceSpecification/
So yes, LogicalResourceSpecificxcation and PhysicalResourceSpecification, as well as all polymorphic extensions of ResourceSpecification, are part of the same collection.
------------------------------
Vance Shipley
SigScale
Original Message:
Sent: Mar 26, 2020 13:28
From: Marcos Donato da Silva
Subject: TMF-634: Why can't we have only Resource Specification to address logical & physical ones
Hello,
I studied implementation of TMF633 where Service Specification serves both for Customer Facing Service Specification and Resource Facing Service Specification scenarios.
Now, I'm checking TMF634 and I can see that we have the general Resource Specification and then, we have Logical Resource Specification (which is basically the same element as the Resource Specification one) and, Physical Resource Specification (which has 3-4 new elements on top of the general Resource Specification element.
My question is: Why can't we have on TMF634 a single element to address both physical and logical resources, being the @type element capable to
differentiate among them.?
------------------------------
Marcos Donato da Silva
Ericsson Inc.
------------------------------