FIX: Allow user input on vertical_domain

[tnatt]

PR that closes #624.

Main problems were:

• vertical_domain were hardcoded to {"depth": "msl"} where the dict value was the depth_reference
• the depth_reference was previously only possible to input for content="depth" (according to the schema)

I have been very much back and forth on how to best solve this one. But after discussions with @jcrivenaes we landed on adding a new general domain_reference argument in ExportData and as field in the schema as the best solution. This will be applicable both for time/depth domains.

Other changes

• deprecate unused depth_reference argument in ExportData
• support giving in vertical_domain as string ("time" or "depth") and deprecate dictionary input
• set the vertical_domain according to the content if content is depth/time,

[mferrera]

I see we use "Optional ", "Optional. ", and "Optional, " to indicate optionality. It's not relevant to this PR, just an observation, but maybe we should align all of these to one if it's reasonable to do so.

[tnatt]

yes, I agree the entire argument documentation should have a go through

[mferrera]

Nice work 👍 a few uniformity nits but not important ones

[mferrera]

Much nicer 😄

[perolavsvendsen]

datum could possibly also be used. Is it a risk that we will have different (whitelisted) allowed domain_references for each content? E.g. "rkb" would make sense for "content: wellpath", but not for "content: field_outline". Would this be messy? (Perhaps that was the reasoning behind the dict input 🤷‍♂️)

[perolavsvendsen]

Different topic, but this is also an example of how the data model struggle to scale beyond data objects containing a single dataset. E.g. for a depth surface, this is fine. But for a table containing different things which have different references, it doesn't work. (Same as with "unit".)

[jcrivenaes]

Different topic, but this is also an example of how the data model struggle to scale beyond data objects containing a single dataset. E.g. for a depth surface, this is fine. But for a table containing different things which have different references, it doesn't work. (Same as with "unit".)

I think we have to live with that. I think the only way to mitigate that may be something like domain_reference="multiple" og "n/a" at top level, and then give spesific data per "sub-type" (like columns in a table).

[jcrivenaes]

datum could possibly also be used. Is it a risk that we will have different (whitelisted) allowed domain_references for each content? E.g. "rkb" would make sense for "content: wellpath", but not for "content: field_outline". Would this be messy? (Perhaps that was the reasoning behind the dict input 🤷‍♂️)

Would data like "field-outline" actually need a domain reference? Since the data itself is "2D" (bird view)

[tnatt]

I don't think the dict input would help in the matter of contents having different allowed references.. it was just a way of setting the vertical_domain together with the reference.
And at the moment I find it difficult to put any logic on the content 🤔 .. some of the contents are quite clear and should be obvious what data it is providing, but many of our contents are general and can be attached to various data... My hope is that much of this gets clearer once we start focusing on 'products' 🤞

[jcrivenaes]

I think is good to go. It is now more scalable for "unknown" future needs; e.g. a domain reference for land-based seismics may be something else than we have currently, but we can easily extend the list.