Transform IDs - Proposed changes

Discussions - ACESNext
1

A number of users and implementers have pointed out inconsistencies and expressed confusion over the specifications in S-2014-002. In addition, I have misinterpreted this document in the past and so many of the transform IDs in the v1.3 CTL transforms are technically wrong according to the spec.

I get about 3 emails per month on this topic, so it’s overdue to propose a fix to this, especially as part of the preparation for an ACES 2.0.

I would love to hear opinions on the topic.
If there is enough interest and discussion, we can organize a (hopefully 1-time) call to iron out details.

What Is Currently Stated in the Specification

Academy components

Academy provided transforms follow this convention:
'URN:Type.NameSpace.Name.aMajorVersionNumber.TransformMinorVersionNumber.TransformPatchVersionNumber'
(This is me abstracting a general form from the many repetitive statements for different transform types.)

where:

  • aMajorVersionNumber indicates the ACES System major version (e.g. ACES 1.x)
  • TransformMinorVersionNumber is intended to track the version of that specific transform.
  • TransformPatchVersionNumber is intended to allow for tracking small changes to the specific transform.
    ( Why aren’t these TransformMajor and Transform Minor?)

An exception is the RRT, which has no NameSpace or Name field:
URN:RRT.aMajorVersionNumber.RRTMinorVersionNumber.RRTPatchVersionNumber
(I guess the Namespace is omitted here because there is theoretically only one RRT and it is Academy supplied, so why provide a namespace?)

Vendor/User-supplied components

However, vendor-supplied transforms are to follow this convention:
'URN:Type.NameSpace.Name.aMajorVersionNumber.vTransformVersionNumber'

where:

  • aMajorVersionNumber indicates the ACES System major version (e.g. ACES 1.x)
  • vTransformVersionNumber indicates the version of the specific transform
    Note that there is no “MinorTransformVersionNumber” for vendor-supplied transforms.

Incrementing

Here is the existing text on when to or not to increment a version number:

Transforms such as the RRT and ODTs rely on sub-functions and constants included in separate CTL files, i.e. ACESlib. ACESlib files often contain more than one sub-function or constant. If a change is made to the code of a sub-function that affects the output of a calling transform, the version of the calling transform’s Transform Identifier shall be incremented (even if the code in the RRT, ODT, etc. itself may not have changed). For simple additions or modifications to an ACESlib file that do not affect the numerical output of a calling function, the calling function version Transform Identifier will not be incremented.

Any transform updates to a transform file (e.g. whitespace changes, modifications to code comments, etc.) that do not change the output of that transform shall not increment the Transform Identifier.

Questions

  • Why is there a major/minor transform version number for Academy transforms but not for vendor/user-supplied?
  • Do we really need a minor/patch distinction as in the Academy-supplied string format? After all, a new version is a new version, right? A single incremented ‘vTransformNumber’ would indicate this. Why do we need a patch?

Proposed Changes

  1. Update the spec with much simpler and clearer statement that all Transform IDs, Academy-supplied or vendor/user-supplied, and including the RRT, use a consistent format:
    URN:Type.NameSpace.Name.aMajorVersionNumber.vTransformVersionNumber

  2. Update the Transform IDs for the transforms in ‘aces-dev’ to adhere to (1) above. However, we would need to decide whether to do this now or wait to reconcile all with an ACES 2.0. How badly would changing those mess up the hard work vendors have been doing on implementation?

2 Likes