Open APIs

Hi all, 

I am confused with Characteristic naming pattern.
In other entities there is an id field which corresponds to the unique identifier of the entity and the name field which is the human readable name of the entity. 
Have you thought about adding something like id to the characteristic and changing the name to something similar with other patterns? What if I had unique name of the characteristic, unique identifier and a human readable name e.g.

id: 1234
name: "fidelityProgram",
humanReadableName: "The fidelity Program of Agreement."

which one of this should be put as the name of the charateristic? In many api examples it looks like the option name (name: "fidelityProgram") should be used, but is there any oportunity to show more descriptive name?

Or do you have your own thoughts?

Best regards,
Adam

------------------------------
Adam Augustyn
Comarch S.A.
------------------------------

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.
------------------------------

Hi Jonathan,
Could you please tell us more about multi-lingual display names? Any link to the CR or more info...
Is there any idea for that? Would it be a separate api/endpoint dedicated for fetching translated display names or new attributes in existing api?

Regards,

------------------------------
Damian Golda
Comarch S.A.
------------------------------

Original Message:
Sent: Oct 12, 2020 11:32
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.
------------------------------

If you are a member of the Open API project, you can see the CR here. https://projects.tmforum.org/jira/browse/AP-1472
I don't think that enough progress has been made there to give you a concrete answer on how it would work.

------------------------------
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: Oct 13, 2020 01:12
From: Damian Golda
Subject: Characteristic id pattern

Hi Jonathan,
Could you please tell us more about multi-lingual display names? Any link to the CR or more info...
Is there any idea for that? Would it be a separate api/endpoint dedicated for fetching translated display names or new attributes in existing api?

Regards,

------------------------------
Damian Golda
Comarch S.A.
------------------------------


Original Message:
Sent: Oct 12, 2020 11:32
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.

Hi @Jonathan Goldberg,

Have a question regarding the id that has been added in the Characteristic, I'm assuming this is unique and is generated by the API provider in the response?

Thanks,
Anu​

------------------------------
Anu Aulakh
Telstra Corporation
------------------------------

Original Message:
Sent: Oct 12, 2020 11:32
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.
------------------------------

Hi Anu
Bear in mind that this is a local ID, optional from API perspective, and unique only within the scope of the Product that contains the Characteristic array. So it's completely an implementation decision whether or not to use it, and if to use it whether it is provider or consumer who takes responsibility.
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: Nov 08, 2022 21:55
From: Anu Aulakh
Subject: Characteristic id pattern

Hi @Jonathan Goldberg,

Have a question regarding the id that has been added in the Characteristic, I'm assuming this is unique and is generated by the API provider in the response?

Thanks,
Anu​

------------------------------
Anu Aulakh
Telstra Corporation
------------------------------


Original Message:
Sent: Oct 12, 2020 11:32
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.

Thanks @Jonathan Goldberg for your prompt response.​

------------------------------
Anu Aulakh
Telstra Corporation
------------------------------

Original Message:
Sent: Nov 09, 2022 06:00
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Anu
Bear in mind that this is a local ID, optional from API perspective, and unique only within the scope of the Product that contains the Characteristic array. So it's completely an implementation decision whether or not to use it, and if to use it whether it is provider or consumer who takes responsibility.
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: Nov 08, 2022 21:55
From: Anu Aulakh
Subject: Characteristic id pattern

Hi @Jonathan Goldberg,

Have a question regarding the id that has been added in the Characteristic, I'm assuming this is unique and is generated by the API provider in the response?

Thanks,
Anu​

------------------------------
Anu Aulakh
Telstra Corporation


Original Message:
Sent: Oct 12, 2020 11:32
From: Jonathan Goldberg
Subject: Characteristic id pattern

Hi Adam
Historically, Characteristic had only name and value (and value type), so the name was its only means of identification, while at the same time being (presumably) human-readable. And so name (and value) are mandatory. Additionally the name is the link to the corresponding characteristic specification (e.g. as expressed in the catalog APIs).
Recently we added id as an optional field, to allow additional flexibility.
The Open API models do not (currently) have the concept of a display name (what you refer to humanreadablename).
This is related to some extent to the ability to define display names with multi-lingual behavior, for which there is an open CR, but no plans to deal with at this time.
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.