...
- Ignore any ACL on a versioned resource; instead honor the ACL that the Original Resource (LDPRv) has by having the LDPCv use that ACL. Essentially the versioned resource resources 'inherit' the ACL from the version container (LDPCv).
- This scenario allows for the LDPRv to potentially have a separate ACL from the versions of itself.
- If the LDPCv has no ACL - default back to the LDPRv?? Or perhaps the LDPCv points to some sort of default ACL?This scenario allows for the LDPRv to potentially have a separate ACL from the versions of itself.
- Any versioned resource always has the same ACL as the Original Resource (LDPRv). In other words, the ACL on the LDPCv LDPRv always applies to all versions of the resource. If the ACL is changed or updated on the LDPCvLDPRv, all the versions then have that same change/update. The ACL would be stored and referenced from the LDPRv (not stored in the versions).
- When a LDPR is versioned, honor the ACL that's on the versioned resource that was there at the time the version was created.
- If the URL of the ACL pointed to never changes, then all the versions will have the same ACL restrictions as the LDPRv.
- If the URL of the ACL pointed to changes over time, then the versions may have different ACL restrictions, from both each other and the Original Resource.
- This scenario gets complicated quickly, especially when an ACL that's on a version, but no longer on the LDPRv, gets removed from the system.
- Version the ACL along with the LDPRv.
- This would be a tricky scenario to work with as an admin would potentially be unable to manage access appropriately. Given that mementos are immutable, the versioned ACLs wouldn't be able to change and an admin would be unable to change authorizations for versions of resources.
...