Make datetime nullable for stac items for which a nominal datatime makes no sense

[cholmes]

As discussed on the call on april 27, we want STAC to be able to represent data cubes and Zarr (#781), so we should relax our requirement that a datetime is needed - a time range should be used instead. The solution we liked was to make it required, but allow a 'null' value.

I believe we said if a null is there then the start_datetime and end_datetime are required.

I'll take this on to start, but will need some help with the schema.

[m-mohr]

I'll take on the schema.

[m-mohr]

Just wanted to make the schema for it, but there's a bit of an issue as datetime is in the item spec and start/end_datetime are in the common metadata. Could we move datetime to common metadata or the other timestamps to the Item spec? As we are about to have a dependency between these fields, it seems also better to list them together in the documentation. I guess we prefer moving start/end_datetime to the item spec? Or maybe we just list them on both pages...

[cholmes]

Hrm... Yeah, actually putting them in the item-spec.md at the exact same level is right over the line for me - I want it to be clear that 'datetime' is the core way. I'm ok to mention and link to them in the item-spec. And I'm ok if we put it in the schema because there's no other way to validate it. I don't think we actually need a one to one from item-spec.md to the item spec schema. To me the item-spec/ directory is 'the item spec', so common metadata is part of the 'spec'. But I really don't want to present two options in the core item-spec.md table.

I guess what I'm saying is I don't think it 'seems also better to list them together in the documentation'. That treats them as equal level. I was going to write the text to link from datetime to the fields as what you do if the datetime is null, but not to list them both.

[m-mohr]

This separation sounds quite confusing. You require datetime, but if it's set to null go somewhere else to figure out the other fields required in this case? With adding null as accepted value you already show a second option in the item spec, but it's then written somewhere else what you need to add instead to use the null option. You can't just hide the "null" option in the item spec, that's really bad spec writing from a dev perspective. You can still say what is the recommended way of doing it if they are shown together. So strictly -1 on your proposal, sorry. If we do it this way, better don't do it at all, because it's really, really confusing. But not doing it will limit STAC from covering certain use-cases well enough.

[cholmes]

I'm not saying hide the null option. I should probably write the text and then we can debate it. But what I was thinking for the line would be:

Field Name	Type	Description
datetime	string	REQUIRED. The searchable date and time of the assets, in UTC. It is formatted according to RFC 3339, section 5.6. A null value is allowed, but should only be used when an extension clearly defines the asset to require start_datetime and end_datetime from common metadata and explains why a nominal datetime can't be used.

[m-mohr]

That's okayish from my perspective, I don't quite think it makes sense to refer to extensions here as we can't enforce this (and I personally would just use it without any extension).

Something like (although not 100% happy myself with the last sentence):

Field Name	Type	Description
datetime	string|null	REQUIRED. The searchable date and time of the assets, in UTC. It is formatted according to RFC 3339, section 5.6. null is allowed, but requires start_datetime and end_datetime from common metadata to be set. null should only be used when there's clearly no meaningful single timestamp available.

[m-mohr]

Okay, I gave it a try here so that we can discuss on something more concrete: #798