Mention that ER references are to-one cardinality only (#101)

* Mention that ER references are to-one cardinality only

Signed-off-by: Simon Heimler <simon.heimler@sap.com>

* Fix links

---------

Signed-off-by: Simon Heimler <simon.heimler@sap.com>

Author: Fannon

docs/primer.md

@@ -264,15 +264,16 @@ Note: As a general convention we recommend to omit optional boolean properties,
 
 ### Cardinality
 
-Please note that CSN Interop does not support arrays of scalar types and arrays of arrays.
-There is [cds.Association](./spec-v1/csn-interop-effective#association-type) (array of pointers) and [cds.Composition](./spec-v1/csn-interop-effective#composition-type) (array of entities), which can express "to many" relationship via the [cardinality](./spec-v1/csn-interop-effective#cardinality-object) object.
+CSN Interop does not support arrays of scalar types and arrays of arrays.
 
-The reason for not supporting arrays of scalar types is that this is not supported in all tech-stacks and would require a more complex mapping.
+There are [cds.Association](./spec-v1/csn-interop-effective#association-type) and [cds.Composition](./spec-v1/csn-interop-effective#composition-type), which can express "to many" relationship via the [cardinality](./spec-v1/csn-interop-effective#cardinality-object) object.
+
+Not supporting arrays of scalar types is a design choice, due to the interoperability quality. Arrays of primitive types are not supported in all tech-stacks (notably relational schemas) and would require a more complex mapping.
 By not supporting this in CSN Interop, the model needs to make the decision how multi-value scalar types are to be mapped.
 
 This can be done, e.g. by:
 
-- converting the scalar type to an Entity and use `cds.Association` or `cds.Composition` with the appropriate cardinality (RECOMMENDED).
+- converting the scalar type to an Entity and use `cds.Composition` (or `cds.Association`) with the appropriate cardinality (RECOMMENDED).
 - converting the array of values into a single string, e.g. by using a delimiter or parsing it to a JSON string.
 
 ## Annotations

spec/v1/annotations/entity-relationship.outro.md

@@ -186,8 +186,7 @@ The annotation is an array because there could be multiple Entity Types that are
 If an array is given, all of the reference targets MUST be valid places where the ID can be resolved, at least in a certain implementation or version of the target entity.
 This also allows for references to polymorphic targets that share the same Property Type as an ID (e.g. a reference to either Cat or Dog, sharing the same Pet ID).
 
-> 🚧 Consideration: Provide optional attribute to state that a reference has a "composition" quality, in case that the API Model itself doesn't imply that already.
-> This would help to know which entity type instances should be deleted if their parent is deleted and is usually also an indicator for transactional integrity.
+**Cardinality**: For references with "to many" cardinality, the property holding the referenced ID must be moved to a separate entity, which is then included as a `cds.Composition` with the desired cardinality. See [cardinality of primitive types](../../primer.md#cardinality).
 
 #### Referencing Composite IDs
 
@@ -244,6 +243,8 @@ entity PurchaseOrder {
 }
 ```
 
+**Cardinality**: For references with "to many" cardinality, the properties that together form a composite reference must be moved to a separate entity, which is then included as a `cds.Composition` with the desired cardinality. E.g. `mainSupplier: SupplierReference` where the new SupplierReference entity contains the `number` and the `type`. See [cardinality of primitive types](../../primer.md#cardinality).
+
 ### Advanced Cases
 
 All the annotations in this section are **optional** for providers and consumers to implement or understand.