Update README.md

README.md

@@ -7,7 +7,7 @@ Approach
 The approach for coming to this standard is to take input from different sources, 
 merge these into a standard and propose that to the working group.
 
-In the DataLinker directory, the work done previously by Rezare et al. can be 
+In the DataLinker directory, the work done previously by Rezare and other organisations can be 
 found. In the JoinData directory, the messages as used and/or proposed in the
 JoinData/CRV/Lely project can be found. Both are largely based on the existing 
 ICAR ADE XML standard and as such overlap largely.
@@ -22,17 +22,20 @@ The principles used are as follows:
 * Primarily focus on the body (message)
   * URL with filter/query parameters are outside of the standard
   * But we could propose a ‘default’ or ‘recommendation’ to allow better discoverability
-  * Create preferred names for url’s, filter parameters, pagination etc
-* Endpoints per message
+  * Create preferred names for url’s
+  * Specification for filter parameters and pagination is within scope
+* Endpoints per message (resource or resource list)
   * Allows specific access to only the data required for the use case 
   * Allows a per-URI mandate
   * Allows a per-vendor decision which URI’s to support
 * Start simple, grow into complexity
   * Optimise for 80% of the use cases
   * Combine messages into complex messages or batches only when a use case proofs it is required
   * Allow vendor-specific properties such as pagination and HATEOAS; create an optional recommendation for that
-* No embedded messages (deviation from proposed standard)
+* No embedded messages 
   * Single endpoint should mean single message 
+  * Embedding should be used for genuinely nested structures (for instance, common metadata, ID formats)
+  * Linking process needs to be explicit (JSON-LD or HATEOAS to be confirmed)
 
 * Avoid output-parameters that steer what the end-point should produce
   * Standard should not dictate the URL pattern