Simeon Warner

I think SHACL tests would be good, but as @azaroth42 notes, there are additional JSON-specific (rather than RDF) requirements that would have to be done is some other way (such...

I'd support a move to requests provided its automation doesn't get in the way of any of the lower level checks we need to do.

I don't think there is any uncertainty about number of encoding/decoding actions. Per https://datatracker.ietf.org/doc/html/rfc3986#section-2.4 encoding SHOULD be done once when the URI is assembled from its component parts, and decoding...

To put the above another way: We don't get a choice of specifying when something should or should not be URI encoded, it is already part of the URI spec...

@azaroth42 - I agree with the above except the encoding of `&` as `%26` when building the manifest URI. I was sloppy when I suggested `ENC(query)` above, sorry! This is...

I feel uncomfortable with the idea that we might require an `inventory.json` just as a way to keep the version directory in implementations that choose otherwise not to have an...

Per slack discussion with @neilsjefferies, I think don't see any benefit of making the `no_content` file a "dot"/hidden file. Questions: 1. Is it allowed to have a `no_content` file AND...

@pwinckles re. https://github.com/OCFL/spec/issues/540#issuecomment-982779257 - yes indeed, good point @neilsjefferies re. https://github.com/OCFL/spec/issues/540#issuecomment-982783608 - if we make it mandatory then we don't have backward compatibility with 1.0... but now I think about...

I **do not** think we should make the [earlier suggestion](https://github.com/OCFL/spec/issues/540#issuecomment-826336045) but with `SHOULD` instead of `MUST` because it doesn't solve the problem: it would still just be a warning to...

@pwinckles : per your comment about validating versions: The [spec](https://ocfl.io/draft/spec/#conformance-of-prior-versions) is clear that versions should be validated against the version they were written to conform to, but this isn't actually...