Clarify how to distinguish a TemporalDimension with an AdditionalDimension object where type = 'temporal'

[lossyrob]

The spec says an AdditionalDimension object can have type 'temporal'. It's unclear to me how one would look at the JSON of a Temporal or Additional dimension with type 'temporal' and determine which one it is. Are client libraries checking if the values are ISO 8601 compliant and making the determination off of that?

[m-mohr]

If you specify an additional dimension with type = temporal, the reference system should be set otherwise the temporal information is pretty meaningless. The ISO8601 temporal dimension doesn't have a reference system. Also, the extent is an array of strings for ISO 8601, which is not the case for the additional dimension (array of numbers). Feel free to re-open if that answer is not sufficient. :-)

[lossyrob]

Should the reference system then be required if the type is temporal and it's an additional dimension? There could be language in the extension spec that then says that's the recommended way to distinguish an additional temporal dim from a temporal dim. Otherwise checking the datatype on the extent feels like a pretty brittle way to have the distinction be machine-readable, and insufficient as the extent is optional.

The addition of the requirement of a reference system seems like it could be an sufficient differentiator if the spec language made it required in the temporal case, or else some other distinguishing factor should be put into place. This was discovered while implementing datacube in PySTAC and trying to determine which type the thing was, so I'm sure would be hit by other client authors if they don't push that distinction down to the user, who would also not be able to clearly make the call in a machine-readable way currently.

[m-mohr]

extent is required in temporal dimension so a check for type == "temporal" and extent is array of strings/null detects the temporal dimension. All others are additional dimensions. But indeed the array of strings detection is not very nice to implement. I'm not sure we should introduce additional requirements, then it's basically a different Dimension Object again.

[lossyrob]

Ah, I see, was confused there. I was thinking about distinguishing an additional, but the process is first to check the extent to see if it exists, and then if it contains strings, and then you have a temporal, otherwise it's additional. Not a great process but at least one exists. Keeping this issue open as I think the README should outline this more clearly; I'll put it on my list of PRs to get to unless someone beats me to it :-)

[m-mohr]

Clarified.