The current up-l3 specs combine the requirements for the service with the requirements for clients communicating with those services. We have found it difficult to parse what we are expected to implement for client code in up-cpp vs what is a behavior expected of the service. For example, it is not clear in the USubscription spec whether the state diagram is something the client does when subscribing to a topic, or if it represents an internal state per-topic within the service.
I would recommend splitting the specs into separate documents. One could focus on the requirements of the service itself, such as its states, behaviors, inputs, and outputs. The other(s) could cover how clients interact with those services - what RPC methods are available, what data they're expected to send, what steps they need to follow, are they expected to subscribe for notifications, etc. The client specs could be defined entirely in terms of layer 2 components and operations, abstracting any protocol details below layer 2.
After splitting these specs, the file tree would probably be something like this:
The current up-l3 specs combine the requirements for the service with the requirements for clients communicating with those services. We have found it difficult to parse what we are expected to implement for client code in up-cpp vs what is a behavior expected of the service. For example, it is not clear in the USubscription spec whether the state diagram is something the client does when subscribing to a topic, or if it represents an internal state per-topic within the service.
I would recommend splitting the specs into separate documents. One could focus on the requirements of the service itself, such as its states, behaviors, inputs, and outputs. The other(s) could cover how clients interact with those services - what RPC methods are available, what data they're expected to send, what steps they need to follow, are they expected to subscribe for notifications, etc. The client specs could be defined entirely in terms of layer 2 components and operations, abstracting any protocol details below layer 2.
After splitting these specs, the file tree would probably be something like this: