Sending UID in a new composition

In the API specs for creating a new composition via POST, the example shows an included uid. This seems strange to me, since it should be the responsibility of the receiving system to create the uid. Because the root needs to be unique within a system, allowing an externally-created uid root places a heavy burden on the receiver to guarantee uniqueness.

Is this intended or just an oversight? If it is intended, what is the reasoning?

In general the server overwrites that value.

But in some implementations of the API, the server could allow the client to specify the uid for the new composition.

Current spec is not wrong, IMHO just allows different ways of implementing that service.

The “client” can be another truster server. In such a scenario the “client server” is allowed to specify the uid.

Client can be anything that consumes the API provided by the “server”, so it can be another server, a middleware, an app, etc.

The issue is not the definition of the client, it is if the “server” trusts the “client” in setting the uids for the compositions. A server can choose to not trust anything coming from an external system.

The question of uniqueness within a given server is easy to check; whether a supplied Guid has already been used elsewhere is a question though. I’m not convinced there is any good argument not to overwrite the Guid at the server…

I would say most implementations rewrite the UID if provided in the payload, though the spec allows it and AFAIK doesn’t require the server to overwrite it. On the other hand, that could be the desired behavior in some environments like integrated systems that allow unique global identification of LOCATABLEs.

The real question is at which point in the spec we allow those extra improbable use cases or reinforce some behavior based on common use. This is important for conformance verification, since a conformance test case might check this behavior and we need a criteria to say which one is accepted.

2 Likes