Cardinality of UUri->{UAuthority,UEntity,UResource}

[sophokles73]

The UUri specification contains a class diagram that suggests that the relations between UUri and its components are 1:1 aggregations, i.e. the UUri.authority, UUri.entity and UUri.resource fields are never empty (null).

Howver, in the corresponding proto3 definition of UUri, the authority, entity and resource fields are (inherently) optional. This fact is also reflected in the code generated from the proto3 in the client libraries. For example, in the Rust library the generated fields are of type Option<T> and in the Java code they also seem to be optional, based on the existence of the UUri.hasAuthority() and UUri.hasEntity() methods.

IMHO we need to define the cardinality and semantics of these relations in the UUri spec document. This would allow implementers to properly deal with the fact that the proto3 definitions may differ from the specified semantics, which might be due to the limitations of the proto3 type system.

[stevenhartley]

• basics/ The ASCIIDoc files are the source of truth for the uProtocol PDU
• up-core-api/ protos define the data model and wire format for interoperability between languages
• up-l1 Transport Specifications define how uProtocol data model is bound (serilzied, transmitted, interpreted) to a particular transport technology
• Language libraries implement the specifications, use the proto defined messages, and provide language specific enablers for developers

[stevenhartley]

Changes to cleanup URI specifications has been completed by #142