You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some label attributes have multiple monikers associated to provide convenience aliases. For instance, in the PanCam meta map, both sub_instrument and camera point to .//psa:Sub-Instrument/psa:identifier. Currently, this results multiple KV pairs, which is a bit messy, and which anecdotally increases the threshold for defining aliases.
We could alternatively allow keys to be string tuples.
Pros:
Only one entry per label attribute; less room for mistakes
Cleaner communication of the availability of aliases; potentially easier to integrate with documentation
Cons:
Unclear what order the aliases should be in (though attribute name first seems sensible)
Loss of static key collision warnings (although this could be covered by a test)
Need to unpack the source meta map dict at runtime anyway
The text was updated successfully, but these errors were encountered:
Alternatively, if we're open to eating the loss of static checking and unpacking cons above, then we could go further: invert the map to deduplicate paths and play on the underlying structure. e.g.:
Some label attributes have multiple monikers associated to provide convenience aliases. For instance, in the PanCam meta map, both
sub_instrument
andcamera
point to.//psa:Sub-Instrument/psa:identifier
. Currently, this results multiple KV pairs, which is a bit messy, and which anecdotally increases the threshold for defining aliases.We could alternatively allow keys to be string tuples.
Pros:
Cons:
The text was updated successfully, but these errors were encountered: