... | ... | @@ -176,7 +176,7 @@ Notice, we are also declaring 3 properties: |
|
|
|
|
|
These act as well-known properties that should be added to the record by your DDMS. Clients can then use this information to retrieve the data after discovery using the registered DDMS API. Every schema used by a DDMS should declare these properties.
|
|
|
|
|
|
## Expose legal tag and ACLs through your APIs
|
|
|
## Expose legal tag and ACLs
|
|
|
Unless you have a scenario where you know what legal tag and ACL should be applied to the data you are storing, you will need to expose the legal tag and ACL in the DDMS ingestion APIs. This allows your clients to supply the legal tag and ACL themselves.
|
|
|
|
|
|
You can expose the same interface as the Storage records API, allowing you to assign them to the record you create.
|
... | ... | @@ -293,7 +293,7 @@ By forwarding on any request by the client to retrieve the record, you can deleg |
|
|
|
|
|
In this scenario, you also don’t need to store the ACL or legal tag information in your DDMS because those are being retrieved directly from the OSDU in this request. However, you need to either store or be able to generate the Storage record ID needed to retrieve the record for the bulk data requested. Therefore using a deterministic ID for the Storage Record is advisable.
|
|
|
|
|
|
## Client retrieves the bulk data <a name="retrieve"></a>
|
|
|
## Client retrieves the bulk data
|
|
|
|
|
|
Imagine the client discovered a record with the following data
|
|
|
|
... | ... | |