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:

ngff/rfc/2/index.md

Line 261 in 106d7d9

- The version information will be moved from the `multiscale`, `plate`, `well` etc. sections into the new `ome` section.

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

However the spec also states that:

ngff/index.bs

Lines 501 to 502 in 8cbba21

	The `plate` dictionary MUST contain a `version` key whose value MUST be a string specifying the
	version of the plate specification.

ngff/index.bs

Lines 545 to 546 in 8cbba21

	The `well` dictionary SHOULD contain a `version` key whose value MUST be a string specifying the
	version of the well specification.

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