There may exist provider or service level hard-coded configurations (cf 3.4.3.c and 3.4.3.g). In both cases the related link of the COM object is NULL.
In the case of a ProviderConfiguration, it may be identified by its body (MAL::Identifier). In the case of a ServiceConfiguration, the body is used to identify the service. There is no other mean to identify the configuration but the id itself. I believe this is a problem.
I can imagine 3 solutions:
1- the ids for ServiceConfiguration objects define a reserved range for hard-coded configurations. There is then a global registry for allocating those ids. I dont like this solution.
2-the body of the ServiceConfiguration object is modified to include a MAL::Identifier. I prefer this solution but it requires a change in the structures.
3- hard-coded service level configuration are forbidden. Only provider level hard-coded configurations are allowed.
Note that from the point of view of implementation, the specification could be left as is. It can be implemented. However I believe it would not be usable.
There may exist provider or service level hard-coded configurations (cf 3.4.3.c and 3.4.3.g). In both cases the related link of the COM object is NULL. In the case of a ProviderConfiguration, it may be identified by its body (MAL::Identifier). In the case of a ServiceConfiguration, the body is used to identify the service. There is no other mean to identify the configuration but the id itself. I believe this is a problem.
I can imagine 3 solutions: 1- the ids for ServiceConfiguration objects define a reserved range for hard-coded configurations. There is then a global registry for allocating those ids. I dont like this solution. 2-the body of the ServiceConfiguration object is modified to include a MAL::Identifier. I prefer this solution but it requires a change in the structures. 3- hard-coded service level configuration are forbidden. Only provider level hard-coded configurations are allowed.
Note that from the point of view of implementation, the specification could be left as is. It can be implemented. However I believe it would not be usable.