Do we need to clarify that `"fixity": null` is not allowed, or should we allow it?

[zimeon]

From zimeon/ocfl-py#79:

@zimeon: I think it is clear in https://ocfl.io/1.0/spec/#fixity "The fixity block MUST contain keys corresponding to the controlled vocabulary given in the digest algorithms listed in the Digests section, or in a table given in an Extension." -- this implies a JSON object but if we want to add further clarification then that would be a spec issue
@pwinckles: Right, but I would interpret that to mean that if there is a fixity block then it must have those properties. The fact that fixity is null, to me, means that it does not have a fixity block. Serializing missing fields to null is typical, and often configurable, for some JSON serializers.

[julianmorley]

I'm a proponent of only listing the fixity block if it has digests in it. Having a random "fixity": {} or similar seems potentially messy.

[rosy1280]

we all agree that if something isn't in the fixity block then the fixity key should not be present.

[pwinckles]

For what it's worth, ocfl-java serializes empty fixity blocks as "fixity": {}. This is a product of how serialization works in Java and best practices around null values. I can update the code to not serialize empty fixity blocks, though I'd prefer not to. This feels like an odd thing to legislate. Clients should be able to handle fixity blocks in json that do not exist, exist but are null, and exist but have no value. This is just basic json parsing.

[pwinckles]

Furthermore, if you were to convince me that it is not a good idea to serialize the empty maps, I still don't see why the spec needs to be involved here. This PR is making it an error to produce what some json libraries produce naturally and every json library should support reading.

[zimeon]

@pwinckles - I do NOT feel we should allow "fixity": null which you brought up earlier as a question, and I thought you were arguing for greater consistency. I can go either way on "fixity": {}

[pwinckles]

To me it doesn't seem necessary to specify because I would expect every client to be able to deal with all 3 empty possibilities because that's the nature of working with json. After deserializing, I cannot tell the difference between a field that was present but with a null value and a field that was not present. I also don't see what the harm is of serializing an empty map.

As noted in the PR, if you do disallow it, contentDirectory, message, and user would also need addressed.

[pwinckles]

In the commit to ocfl-py, the example inventories have empty state and manifest maps. It seems inconsistent to me to forbid that for fixity but accept it other places.

[zimeon]

Yes, that is why I feel it would be OK to allow {}.

I still think null is quite different, even if that Java library treats it the same as {}

[pwinckles]

I still think null is quite different, even if that Java library treats it the same as {}

It would be the case with any non-map based representation of json. It is simply not possible to know if a field was explicitly set to null or was not present. It's not a problem if you want to disallow it, it bothers me less than disallowing empty maps, but, to me, it seems like an odd thing to call out.