Open APIs

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

I looked further into this, there is an existing JIRA for this waiting to be executed.

https://projects.tmforum.org/jira/browse/AP-2928

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

I am coming back to my original question.

Thank you, @Jonathan Goldberg, for the information.

This JIRA (https://projects.tmforum.org/jira/browse/AP-2928) is indeed related, but seems to be more focused on the RelationshipCharacteristicSpecification in TMF620 than on the RelationshipCharacteristic in TMF637.

The only reference to TMF637 I can find there is this comment at the end:

But I find it confusing, because, as I wrote in my original post, the Swagger of TMF637 does NOT contain RelationshipCharacteristic.

@Matthieu Hattab - with regards to your message: "The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue." I do not exactly understand what you mean. The way I understand it, the common pattern is to have all specifications in Catalog Management, and all instances in Inventory Management. For example, you can have RelatedEntitySpecification in some catalog, and RelatedEntity in the corresponding Inventory. Shouldn't it be the same with RelationshipCharacteristicSpecification/RelationshipCharacteristic?

I looked further into this, there is an existing JIRA for this waiting to be executed.

https://projects.tmforum.org/jira/browse/AP-2928

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

the product in the inventory has a reference to the Product Specification:

you can query that product spec with TMF620 V5 and then you can see the productspecificationrelationship and the characteristic that refines the
relationship.
I'm not sure the characteristic that refines the relationship should be instanciated in the product inventory. That characteristic is used to enforce a business rule.
if possible we should keep the api payload as lean as possible.
Why do you need it for?

I am coming back to my original question.

Thank you, @Jonathan Goldberg, for the information.

This JIRA (https://projects.tmforum.org/jira/browse/AP-2928) is indeed related, but seems to be more focused on the RelationshipCharacteristicSpecification in TMF620 than on the RelationshipCharacteristic in TMF637.

The only reference to TMF637 I can find there is this comment at the end:

But I find it confusing, because, as I wrote in my original post, the Swagger of TMF637 does NOT contain RelationshipCharacteristic.

@Matthieu Hattab - with regards to your message: "The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue." I do not exactly understand what you mean. The way I understand it, the common pattern is to have all specifications in Catalog Management, and all instances in Inventory Management. For example, you can have RelatedEntitySpecification in some catalog, and RelatedEntity in the corresponding Inventory. Shouldn't it be the same with RelationshipCharacteristicSpecification/RelationshipCharacteristic?

I looked further into this, there is an existing JIRA for this waiting to be executed.

https://projects.tmforum.org/jira/browse/AP-2928

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

Hello Matthieu,

Instantiation of such a characteristic addresses your other question. In your example:

A CharacteristicSpecification of the ProdSpecRelationship defines the options of required bandwidth, and an instantiation will define the bandwidth that is actually selected for the specific instance of TVProd.

Does this make sense?

the product in the inventory has a reference to the Product Specification:

you can query that product spec with TMF620 V5 and then you can see the productspecificationrelationship and the characteristic that refines the
relationship.
I'm not sure the characteristic that refines the relationship should be instanciated in the product inventory. That characteristic is used to enforce a business rule.
if possible we should keep the api payload as lean as possible.
Why do you need it for?

I am coming back to my original question.

Thank you, @Jonathan Goldberg, for the information.

This JIRA (https://projects.tmforum.org/jira/browse/AP-2928) is indeed related, but seems to be more focused on the RelationshipCharacteristicSpecification in TMF620 than on the RelationshipCharacteristic in TMF637.

The only reference to TMF637 I can find there is this comment at the end:

But I find it confusing, because, as I wrote in my original post, the Swagger of TMF637 does NOT contain RelationshipCharacteristic.

@Matthieu Hattab - with regards to your message: "The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue." I do not exactly understand what you mean. The way I understand it, the common pattern is to have all specifications in Catalog Management, and all instances in Inventory Management. For example, you can have RelatedEntitySpecification in some catalog, and RelatedEntity in the corresponding Inventory. Shouldn't it be the same with RelationshipCharacteristicSpecification/RelationshipCharacteristic?

I looked further into this, there is an existing JIRA for this waiting to be executed.

https://projects.tmforum.org/jira/browse/AP-2928

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

the modification you've done on my diagram would work for TMF620. (I'm hoping Jonathan can confim it because that would mean I need to split my TVProdSpec:

1. one 8KTVProdSpec for 8K channels, where I could add the CharSpec under the ProdSpecRelationship to restrict certain bandwidth values on the Fiber PS, as you updated on my diagram
2. another one for other resolutions (4K, HD and SD)

However my model was really for TMF620.
do you have a need ot see the characteristic under the productrelationship in TMF637?

Hello Matthieu,

Instantiation of such a characteristic addresses your other question. In your example:

A CharacteristicSpecification of the ProdSpecRelationship defines the options of required bandwidth, and an instantiation will define the bandwidth that is actually selected for the specific instance of TVProd.

Does this make sense?

the product in the inventory has a reference to the Product Specification:

you can query that product spec with TMF620 V5 and then you can see the productspecificationrelationship and the characteristic that refines the
relationship.
I'm not sure the characteristic that refines the relationship should be instanciated in the product inventory. That characteristic is used to enforce a business rule.
if possible we should keep the api payload as lean as possible.
Why do you need it for?

I am coming back to my original question.

Thank you, @Jonathan Goldberg, for the information.

This JIRA (https://projects.tmforum.org/jira/browse/AP-2928) is indeed related, but seems to be more focused on the RelationshipCharacteristicSpecification in TMF620 than on the RelationshipCharacteristic in TMF637.

The only reference to TMF637 I can find there is this comment at the end:

But I find it confusing, because, as I wrote in my original post, the Swagger of TMF637 does NOT contain RelationshipCharacteristic.

@Matthieu Hattab - with regards to your message: "The inventory API already has references to the Product Offering and Product Specifications, so one could easily find the PS relationships from the product catalogue." I do not exactly understand what you mean. The way I understand it, the common pattern is to have all specifications in Catalog Management, and all instances in Inventory Management. For example, you can have RelatedEntitySpecification in some catalog, and RelatedEntity in the corresponding Inventory. Shouldn't it be the same with RelationshipCharacteristicSpecification/RelationshipCharacteristic?

I looked further into this, there is an existing JIRA for this waiting to be executed.

https://projects.tmforum.org/jira/browse/AP-2928

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

Hi Matthieu

The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

Hi,

the defintion in the API user guide says:

do you have a working illustration of the above definition?

I can't find a way to model the example provided in the user guide:

Hi Matthieu

The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

Hi @Matthieu Hattab.

I was looking for any topic regarding productSpecificationRelationship - characteristic and found this discussion. Unfortunately your last question is not answered. Have you found the way how to model the relationship between broadband and TV since your last post?

Hi,

the defintion in the API user guide says:

do you have a working illustration of the above definition?

I can't find a way to model the example provided in the user guide:

Hi Matthieu

The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

It should probably be added to the inventory API, thanks for the catch Opher.

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

Hi,

As the TMF Product Catalogue only supports simple business rules, we opted not to use it for storing our business rules. Over time, we've realised that it has too many gaps and compromises, making it unsuitable for our needs.

Currently, all our business rules are implemented in code within TMF components such as the Product Configurator, Product Offering Qualification, Service Qualification, and Product Recommendation. However, this approach is not scalable.

We are actively investigating external rule engines, potentially something similar to the ECA model from the TMF Policy component. A dedicated policy component could support product, pricing, and eligibility rules without the constraints of the TMF Product Catalogue. Rules can be stored with Decision table, FEEL language which are a low-code/no-code solutions to manage rules' conditions.

Tools under consideration:

• Gorules
• Drools/Kogito/jBPM/OptaPlanner (suite)
• OpenRules
• Nected
• Camunda DMN
• ...

A key issue is that these rule engines are not self-contained. They require all relevant facts to be provided upfront in the API request, which violates TMF API compliance. One of the core ODA component principles is that they must be self-contained. And TMF API are not designed to provide relevant facts upfront in the API POST request.

To address this, we may need a hybrid approach, combining a rule engine with an event-driven orchestrator (e.g., n8n, Node-RED, Camunda, or Apache NiFi) to handle "missing" facts. Alternatively, we could implement built-in dynamic fact retrieval within the rule engine. Some developers have also suggested using introspection.

It's a complex challenge.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Tele AS

Original Message:
Sent: Feb 04, 2025 02:27
From: Jan Brnka
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi @Matthieu Hattab.

I was looking for any topic regarding productSpecificationRelationship - characteristic and found this discussion. Unfortunately your last question is not answered. Have you found the way how to model the relationship between broadband and TV since your last post?

------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.

Original Message:
Sent: Dec 04, 2023 11:17
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi,

the defintion in the API user guide says:

do you have a working illustration of the above definition?

I can't find a way to model the example provided in the user guide:

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Nov 29, 2023 15:05
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi Matthieu

The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.

------------------------------
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 28, 2023 18:12
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Nov 26, 2023 07:46
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

It should probably be added to the inventory API, thanks for the catch Opher.

------------------------------
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 24, 2023 08:00
From: Opher Yaron
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

------------------------------
Opher Yaron
Proximus SA
------------------------------

Thank you Matthieu for the answer! Very useful and comprehensive (as always :) ).

The conclusion for me is that the example of "relationship between broadband and TV" is not covered by productSpecificationRelationship - characteristic. So what's the goal/purpose of productSpecificationRelationship - characteristic? Could you please provide an example? 

Regarding the TMF Policy Component, I was unable to find detailed information. I did come across the TMF723 Policy Management API and found the Swagger file, but there is not a corresponding user guide. Although I found a brief reference in the GB922 documents, there was no concrete example like in other user guides. Could you please provide an example, particularly one illustrating the "broadband and TV" scenario?
------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.

Original Message:
Sent: Feb 04, 2025 05:41
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi,

As the TMF Product Catalogue only supports simple business rules, we opted not to use it for storing our business rules. Over time, we've realised that it has too many gaps and compromises, making it unsuitable for our needs.

Currently, all our business rules are implemented in code within TMF components such as the Product Configurator, Product Offering Qualification, Service Qualification, and Product Recommendation. However, this approach is not scalable.

We are actively investigating external rule engines, potentially something similar to the ECA model from the TMF Policy component. A dedicated policy component could support product, pricing, and eligibility rules without the constraints of the TMF Product Catalogue. Rules can be stored with Decision table, FEEL language which are a low-code/no-code solutions to manage rules' conditions.

Tools under consideration:

• Gorules
• Drools/Kogito/jBPM/OptaPlanner (suite)
• OpenRules
• Nected
• Camunda DMN
• ...

A key issue is that these rule engines are not self-contained. They require all relevant facts to be provided upfront in the API request, which violates TMF API compliance. One of the core ODA component principles is that they must be self-contained. And TMF API are not designed to provide relevant facts upfront in the API POST request.

To address this, we may need a hybrid approach, combining a rule engine with an event-driven orchestrator (e.g., n8n, Node-RED, Camunda, or Apache NiFi) to handle "missing" facts. Alternatively, we could implement built-in dynamic fact retrieval within the rule engine. Some developers have also suggested using introspection.

It's a complex challenge.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Tele AS

Original Message:
Sent: Feb 04, 2025 02:27
From: Jan Brnka
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi @Matthieu Hattab.

I was looking for any topic regarding productSpecificationRelationship - characteristic and found this discussion. Unfortunately your last question is not answered. Have you found the way how to model the relationship between broadband and TV since your last post?

------------------------------
Jan Brnka
T-Mobile Czech & Slovak Telekom, a.s.

Original Message:
Sent: Dec 04, 2023 11:17
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi,

the defintion in the API user guide says:

do you have a working illustration of the above definition?

I can't find a way to model the example provided in the user guide:

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Nov 29, 2023 15:05
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hi Matthieu

The way the characteristic relationship is currently defined for APIs, I don't think it meets your needs. It gives you a connection between characteristics, not between their values. The SID takes this one level further and gives you a relationship between characteristic spec values.

------------------------------
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 28, 2023 18:12
From: Matthieu Hattab
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

@Jonathan Goldberg,
Using the characteristic relationship between ProductSpecificationRelationship and CharacteristicSpecification and the provided description, does it support creating relationship between charvalues of 2 different ProdSpec? Using the textual example in the API documentation, can we achieve this:

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Nov 26, 2023 07:46
From: Jonathan Goldberg
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

It should probably be added to the inventory API, thanks for the catch Opher.

------------------------------
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 24, 2023 08:00
From: Opher Yaron
Subject: Characteristic array under Relationship pattern in version 5 of TMF APIs

Hello,

The question is whether version 5 of the APIs intends to contain a Characteristic array under the Relationship pattern.

I reviewed one pair of APIs that already have version 5 in Production - TMF620 Product Catalog and TMF637 Product Inventory.

In the Swagger of TMF620 I find:

In particular, ProductSpecificationRelationship contains a "characteristic" attribute of type CharacteristicSpecification.

However, in the Swagger of TMF637 I find:

In particular, ProductRelationship does not contain a "characteristic" attribute.

The two specifications seem incompatible to me. Do I miss something? If not, which one of these 2 APIs is 'correct'?

Thank you and best regards,

------------------------------
Opher Yaron
Proximus SA
------------------------------