Nomenclature drift between TsInterpMode / TsExtrapMode identifiers and USDA text tokens

[asluk]

In pxr/base/ts/types.h L82-110, the 0-value of the spline interpolation and extrapolation enums is named TsInterpValueBlock and TsExtrapValueBlock:

enum TsInterpMode
{
    TsInterpValueBlock  = 0,  //< No value in this segment.
    TsInterpHeld        = 1,
    TsInterpLinear      = 2,
    TsInterpCurve       = 3
};

enum TsExtrapMode
{
    TsExtrapValueBlock    = 0, //< No value in this region.
    ...
};

However, the USDA text serialization (PEG SplineInterpMode / SplineExtrapolation) emits the token none for the same 0-value, not valueBlock. This split was surfaced during an AOUSD Core Spec 1.1 review of spline terminology:

• The Core Spec's interpolation/extrapolation mode enums (document data model) use none — aligned with the USDA text token.
• The Core Spec's Value Resolution prose and pseudocode use value-block / ValueBlock — aligned with the C++ identifier.

The Core Spec has a path to reconcile internally (adding a mapping note in the affected enums, which is being tracked in the Core Spec repo). But the drift inside OpenUSD itself is not currently documented in user-facing places:

1. The doxygen on TsInterpValueBlock / TsExtrapValueBlock does not mention that these values are serialized as none in USDA.
2. USDA documentation of spline interpolation/extrapolation modes does not cross-reference the internal identifier.

The drift appears intentional — none is more readable in a text file; ValueBlock is more precise in source. But without a note, readers traversing between USDA files and the C++ API have to infer the mapping.

Request: either (a) add doxygen cross-references mapping TsInterp*ValueBlock ↔ USDA token none (and the equivalent for extrapolation), or (b) confirm this is intentional and we will document the mapping purely on the AOUSD Core Spec side.

Discovered during an AOUSD Core Spec 1.1 spline walkthrough.

[jesschimein]

Filed as internal issue #USD-12107

(This is an automated message. See here for more information.)

[spiffmon]

Absolutely makes sense to document in the USDA parser, though it's tricky to discuss a downstream decision in the Ts code, though your "bouncing reader" concern is legit. We'll have a think at this.