Problem Statement
Before we're able to finalize the Interop ID recommendation, there are some questions that have come up during the discussions that we need a better solution for:
- How do we prevent namespaced IDs from becoming "orphaned" if they become part of an official CIF recommendation? E.g., if
ocio:arrilogc4_awg4_scene becomes arrilogc4_awg4_scene, how do we ensure that references to the original ID continue to work?
- We need to acknowledge that people may create IDs without a namespace (perhaps as a result of the first problem). Let's try to ensure this doesn't break things too badly.
- How do we enable applications to generate an ID on the fly when they are unable to find an existing ID for a given color space? If we want to enable people to move from their proprietary OpenEXR metadata to exclusively using the colorInteropID, this is a requirement.
- What is the fallback mechanism in OCIO when searching for a namespaced ID? At various points we have decided to search without the namespace, but at other times we've decided not to.
Proposal
I'll start the discussion with a proposal that I think addresses some of the above issues. The basic idea is to extend the ID to have a two-level namespace.
In previous discussions around point 4, everyone agreed that the solution to point 1 would be to search for the base ID as a fallback. However, we were reluctant to adopt that approach out of concern that there would be unwanted collisions.
The most likely source of collisions is related to point 3. I'm less worried about collisions where an organization choose a name, for example, a digital cinema camera vendor. This is because when the CIF develops new recommendations, we will likely be aware of the IDs that are out there and, even if not, presumably if anyone is already using an ID that appears in a draft recommendation, they will alert us to it. However, if an application needs to generate an ID on the fly, that could easily be a source of collisions.
So the proposal is that if an application needs to generate an ID, it must use a two-level namespace of the form:
<DOMAIN>:<NAMESPACE>:<BASE-ID>
If desired, this could be shortened to:
<DOMAIN>::<BASE-ID>
Then, when OCIO searches for an Interop ID, the search will proceed as follows:
- Search for the full interop ID.
- Drop the front namespace (and colon) and search for the remaining ID.
Step 2 ensures that ocio:arrilogc4_awg4_scene will continue to work in configs that only have arrilogc4_awg4_scene.
A two level namespace would still have a colon prefix in step 2 and would not match just the base ID. However, it could match a namespace and base ID. The latter seems potentially useful as a way of allowing generated IDs that could work across multiple domains.
The recommended method for an OCIO-based app to generate an ID on the fly (when no interop ID exists) is:
- Chose the domain string. This could be based on the application or vendor name. It may not be empty.
- Chose the namespace string. This could be the config name attribute (in the config file), if present. It could be based on the show or project name. Or it could be optionally left empty.
- Use a color space name or alias as the base ID. If the color space name contains a character that is not allowed in an ID, check the aliases. If a legal alias doesn't exist, the app would need to make up a name (though at that point, it would be of limited utility).
Examples
ocio:arrilogc4_awg4_scene matches arrilogc4_awg4_sceneocio:arrilogc4_awg4_scene does not match arri:arrilogc4_awg4_sceneautodesk:show-name:srgb does not match srgbautodesk:show-name:srgb matches show-name:srgbautodesk::srgb does not match srgb
Problem Statement
Before we're able to finalize the Interop ID recommendation, there are some questions that have come up during the discussions that we need a better solution for:
ocio:arrilogc4_awg4_scenebecomesarrilogc4_awg4_scene, how do we ensure that references to the original ID continue to work?Proposal
I'll start the discussion with a proposal that I think addresses some of the above issues. The basic idea is to extend the ID to have a two-level namespace.
In previous discussions around point 4, everyone agreed that the solution to point 1 would be to search for the base ID as a fallback. However, we were reluctant to adopt that approach out of concern that there would be unwanted collisions.
The most likely source of collisions is related to point 3. I'm less worried about collisions where an organization choose a name, for example, a digital cinema camera vendor. This is because when the CIF develops new recommendations, we will likely be aware of the IDs that are out there and, even if not, presumably if anyone is already using an ID that appears in a draft recommendation, they will alert us to it. However, if an application needs to generate an ID on the fly, that could easily be a source of collisions.
So the proposal is that if an application needs to generate an ID, it must use a two-level namespace of the form:
<DOMAIN>:<NAMESPACE>:<BASE-ID>If desired, this could be shortened to:
<DOMAIN>::<BASE-ID>Then, when OCIO searches for an Interop ID, the search will proceed as follows:
Step 2 ensures that
ocio:arrilogc4_awg4_scenewill continue to work in configs that only havearrilogc4_awg4_scene.A two level namespace would still have a colon prefix in step 2 and would not match just the base ID. However, it could match a namespace and base ID. The latter seems potentially useful as a way of allowing generated IDs that could work across multiple domains.
The recommended method for an OCIO-based app to generate an ID on the fly (when no interop ID exists) is:
Examples
ocio:arrilogc4_awg4_scenematchesarrilogc4_awg4_sceneocio:arrilogc4_awg4_scenedoes not matcharri:arrilogc4_awg4_sceneautodesk:show-name:srgbdoes not matchsrgbautodesk:show-name:srgbmatchesshow-name:srgbautodesk::srgbdoes not matchsrgb