Open APIs

In the TMF645 Query SearchCriteria, the service ServiceRefOrValue appears to have multiple purposes, making its interpretation ambiguous.

The description says: "A Service to be created defined by value or existing defined by reference" and its role is outlined in the three Sample Use Case bullets in the TMF645 User Guide:

• Bullet 1: Describe the search criteria for a new desired service - as shown in the example by providing a place where the new service should be created
• Bullet 2: Describe an existing service in the context of which, a new service is qualified
• Bullet 3: Describe the a query about possible options to modify an existing service

Now assume you want to qualify a TV service in a specific place on top of an existing access service.

An existing access service might be cable/fiber based or it could also be a mobile service that does not have an inherent associated place, but where the available bandwidth might depend on the place.

So we get this strange, hybrid service in the SearchCriteria, that is partly describing the access service that is being leveraged (the id and subscription details - 4G, 5G etc) and partly a place that belongs to the query, not the existing service.

Furthermore, if the query is persisted, there is a confusion about the id and href of the persisted ServiceRefOrValue because it is now a persisted resource that ought to be addressable by its href, but the href may or may not be that of an existing service instead.

Questions:

1. For creating a new service in the context of an existing service, I would propose instead to use the ServiceRelationship, as that would disambiguate the existing service from the qualified one.
   1. Is this interpretation correct and as intended by the standard?
   2. One problem with that is that there is no standard for the relationshipType, so we have to invent our own types, so would this interpretation compromise interoperablity?
2. For qualifying a modification of an existing service...
   1. How do I distinguish the id of the existing service from the id of the search service?
   2. Is it acceptable that the search service has no id and href of its own?
   3. Can the id and href be empty if a persisted search service is not representing an existing service? (That violate RESTful principles, but that may be OK since the API does not mandate direct access to sub-resources)

Clearly, the fact that these are "task resources" does make a difference in the interpretation of the objects, and that is the cause of the ambiguities.

But since the standard doesn't clearly specify how to represent the three cases, I have to ask this community about the correct interpretation.

Thanks in advance,

Peter