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.
------------------------------
Original Message:
Sent: Oct 12, 2020 11:19
From: Adam Augustyn
Subject: Characteristic id pattern
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.
------------------------------