Hi Rati
Yes you have made your requirements very clear.
However I am still not sure that that the Documents API is what you are looking for.
In my opinion, schemas need to be managed like software code assets, using source code control (like Git). You will almost certainly have software (e.g. java code) that is written specifically for your IPv4 service (and other services), and this code will relate to the attributes in your schema. So if your schema changes then your code will change, and vice-versa.
The TMF Open APIs are not intended for software configuration management, rather for telco business processes.
Perhaps
@Vance Shipley has an opinion on this as well, we have had prior discussions on the semantic meaning of the @schemaLocation value.
Anyway I hope these insights are helpful, whether or not you agree with them.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Aug 25, 2020 02:47
From: Rati Mehrotra
Subject: TMF 667 and schemafication
Hi @Jonathan Goldberg
We are planning to introduce schema capability for reusing the serviceSpecCharacteristicValue when the valueType is object(complex service characteristics ) across various services. For that we were planning to use the 667 API to manage the CRUD operations on the schemas( could be a json/yaml file)
This can also be used for holding schemas for any polymorphic extension that we do to the TMF APIs which we adopt.
Please let me know if this gives an understanding of our requirements ?
Hi @Steve Harrop,
Can you please provide more understanding on the API and if the 667 API is suitable for the usage that I have mentioned above. We were also looking for the latest documentation on the API.
Thanks,
Rati
------------------------------
Rati Mehrotra
Telstra Corporation
Original Message:
Sent: Aug 24, 2020 09:12
From: Jonathan Goldberg
Subject: TMF 667 and schemafication
Hi Rati
1) TMF 667 is Document Management - it has nothing to do with management of objects and schemas, rather it relates to formal documents that need to be handled and tracked as part of telco business processes. For example a contract with a business customer.
2) TMF 667 was being worked on by @Steve Harrop, but I am not sure what the current status is. In any case as I said in 1) I'm not sure it is relevant to what you are trying to achieve. But maybe I missed something and you have come up with a new use case for this API.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Aug 24, 2020 02:30
From: Rati Mehrotra
Subject: TMF 667 and schemafication
Hi All,
We have few Provider Domains who have complex service specifications. For those providers, to define the specification in the catalog using TMF 633 below is the code snippet that they can use .
"serviceSpecCharacteristicValue": [
{
"valueType": "object",
"isDefault": true,
"value": {
"minInstances": 1,
"maxInstances": 1000,
"@type": "IPv4AttributesObject",
"@schemaLocation": "https://mycsp.com:8080/tmf-api/schema/Service/IPv4AttributesObject.schema.json"
},
We are working on automating the schema management for all such complex objects and was wondering if there is already any TMF API that can be used. We came across TMF 667 and found it quite useful to upload such complex schemas. Few queries :
1) Is TMF 667 the correct API for schemafication of complex service characteristics or is there any other way that anyone has used for this requirement?
2) The latest version we see in Open API Table is 17.0.1 . Is there any latest version being released as we could not find anything in beta versions on this API?
------------------------------
Rati Mehrotra
Telstra Corporation
------------------------------