Thanks for your response. This is indeed an interesting thread and a concern raised by the developers as well. We have recently adopted 640v4 and it not having strongly typed pattern. What is the indicative timeline of incorporating this . If there is any reference to this, please share.
Original Message:
Sent: Dec 18, 2020 04:09
From: Ludovic Robert
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hello Hari
I have probably took a wrong example and use Party information as characteristic example is not a good example and could confuse people. I should have took some example based on product/Service/resource characteristics.
Indeed if we need to capture contact medium we'll not use characteristic but existing contact medium class.
Now about the characteristic pattern with Object datatype - for me we can expect to have a characteristic specification described in the catalog and in this payload you instantiate it. The use of the ObjectCharacteristic allows you to describe complex structure - for example we can describe connectivity with several bandwith profile(s) and associated class of service.
Hope it helps and again sorry for the confusion,
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Dec 18, 2020 00:01
From: Hari mv
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Thanks Ludovic.. It helps..
In your example, if there is one more email address, how will that be modelled. I have pasted couple of options below, if that is ok? I'm trying to model the 5G policy data, where each subscriber will be part of different slices and each slices will have different DNNs for example, but the name of the fields is the same in each sub-blocks, like email-address or phone..
{ "name": "PartyIdentityData", "id": "4df5-7tt", "@type": "ObjectCharacteristicValue", "value": { "giventName": "Jean", "familyName" : "Pontus", "contactMedium": { "emailAddress1": "jean.pontus@orange.fr", "emailAddress2": "jean.pontus@yahoo.com", }, }
{ "name": "PartyIdentityData", "id": "4df5-7tt", "@type": "ObjectCharacteristicValue", "value": { "giventName": "Jean", "familyName" : "Pontus", "contactMedium1": { "emailAddress11": "jean.pontus@orange.fr", "emailAddress12": "jean.pontus@yahoo.com", "phone11": "123456789" }, "contactMedium2": { "phone21": "987654321", }, }}
------------------------------
Hari mv
TO BE VERIFIED
Original Message:
Sent: Dec 17, 2020 09:43
From: Ludovic Robert
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hello Hari
Moving forward we plan to use @type as a discriminator and allow to manage value datatype accordingly.
Then the payload could be... example for a complex characteristic, a string one and an integer one:
"characteristic": [ { "name": "PartyIdentityData", "id": "4df5-7tt", "@type": "ObjectCharacteristicValue", "value": { "giventName": "Jean", "familyName" : "Pontus", "contactMedium": { "emailAddress": "jean.pontus@orange.fr" }, } }, { "name": "Pxxxx", "id": "4xxx", "@type": "StringCharacteristicValue", "value": "blu" } { "name": "speed", "id": "1", "@type": "IntegerCharacteristicValue", "value": 17 } ]
Hope it helps
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Dec 17, 2020 06:39
From: Hari mv
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Is there a conclusion on this topic.
What is the right way to model the complex/arrays/subarrays within the service characteristics.
For example, modeling:
name1.A.X
name1.A.Y
name1.B.P
name1.B.Q
Thanks,Harishankar
------------------------------
Hari mv
TO BE VERIFIED
Original Message:
Sent: May 29, 2020 03:58
From: Ludovic Robert
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hello Chio
This is a very good question.
For me yes you could define an IPAddressCharacteristic as a Characteric specialization and define a IPAddressCharacteristic class.
Alternative is also to leverage valueType - in this case the @type is StringCharacteristic and the valueType = "IPaddress".
Both could work but I do not have enough feedback to comment more.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: May 28, 2020 05:25
From: Chio Chuan Ooi
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hi Ludovic/Jonathan,
Notice that the ServiceCharacteristic will be change to Abstract Characteristic, is that mean to say that we can customize to create our own Characteristic beside the StringCharacteristic or BooleanCharacteristic.
For example, IPAddressCharacteristic that extending Characteristic?
------------------------------
Chio Chuan Ooi
SingTel Optus
Original Message:
Sent: Mar 19, 2020 10:29
From: Ludovic Robert
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hi Adrian
Like Jonathan wrote it....we're working on this to quickly the any and instead leverage @type to select a subclass (featuring strong data type for value) . With current proposal the formal definition will be in the swagger structure. We'll come back quickly on this with Service Order API as illustration.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Jul 11, 2018 17:57
From: Adrian Ofterdinger
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Thanks, Sergey. However, from a formal perspective there is no clear definition on that. I can put any JSON structure in value. I would prefer a formal definition of the structure....
Adrian
------------------------------
Adrian Ofterdinger
Capgemini
Original Message:
Sent: Jul 09, 2018 02:08
From: Sergey Lukin
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Hi Adrian,
ServiceCharacteristic have valueType, which can be complex structure (like table or array)
------------------------------
Sergey N Lukin
Original Message:
Sent: Jul 07, 2018 15:16
From: Adrian Ofterdinger
Subject: TMF641: Service Ordering API: Service Chararcteristic / Value
Dear TMF641 Committers and Experts,
in the TMF641 API, a specific service has n Characteristics with one value each. My question is:
- How to work with lists of values in within one characteristic?
- How to work with nested types of characteristics
Thanks in advance
Adrian
------------------------------
Adrian Ofterdinger
Capgemini
------------------------------