Are previous version keys allowed in v0.5?

[ziw-liu]

Context: I'm implementing v0.5 and need a clear definition of various version fields in the v0.4/v0.5 spec (MUST, MUST NOT, SHOULD, MAY etc).

From RFC-2:

https://github.com/ome/ngff/blob/106d7d9d5726182226ca49297b058570707c354b/rfc/2/index.md?plain=1#L261

And the latest JSON schema do not contain .ome.plate.version, .ome.multiscales[0].version etc.

However the spec also states that:

https://github.com/ome/ngff/blob/8cbba216e37407bd2d4bd5c7128ab13bd0a6404e/index.bs#L501-L502

https://github.com/ome/ngff/blob/8cbba216e37407bd2d4bd5c7128ab13bd0a6404e/index.bs#L545-L546

So we have the following situation, using .ome.plate.version as an example:

• RFC-2, JSON examples in the v0.5 spec, and the schema indicate that having this field should cause a validation error.
• The v0.5 spec text says that NOT having this field should cause a validation error.

Different implementations can interpret these requirements in ways that are not compatible with each other.

[normanrz]

That needs correcting in the spec doc. Neither plates nor wells should have a version key.

[dstansby]

Since the JSON schema is just one implementation of the specification, I think the thing to do here is:

• Fix the JSON schema to match the specification
• Change these fields in v0.6 of the specification so they are removed as intended originally for v0.5