...
- 4.1.2 The Fcrepo spec doesn't mention it directly, but is there a conflict between the Memento "Content-Location" header and External File's "Content-Location"? Can they both appear in the same response?
- External File Content-Location header just appears on LDP-NR HEAD/GET requests, while Memento uses the header for responses from LDPRm and maybe LDPRv, both of which are LDP-RS's. So the headers should not both appear on the same response
- 4.1.3.1 In supporting PUT to LDPRv in order to create a LDPRm, is this just included for server managed versions? Or is PUT to an LDPRv intended to be addressable separately from a LDPR so as to trigger this behavior?
- 4.3.1 How do you determine what serializations are available for TimeMaps? HEAD is not currently supported and is not in the Memento spec.
- GET response formats are not actually listed in any other requests, only for Post and Patch.
- However, it would likely be helpful to include info about HEAD and GET requests in the spec
- 4.3.1 What is the default serialization for GET requests to LDPCv? The only required encoding is application/linked-format.
- 4.3.5 What is the expected behavior if a POST to an LDPCv is made which specifies a Memento-Datetime that is already in use by an existing LDPRm for that LDPRv?
- Having two memento's with the same datetime would result in datetime negotiation yielding indeterminate results.
- Ignore request and return a 412 response? Delete and replace the existing version?
- This could be something we decide - perhaps the new one overwrites the existing one?
- 4.5 Does the modeshape fcrepo currently have a server managed option for versioning?
- We need to make sure that a server managed scenario knows how to handle an LDPCv correctly - in that it doesn't version that resource if a user issues a PUT against it (as a user would if they want the original resource LDPRv to get versioned).
...