Spotfire Mods vs Native Visuals

After working extensively with Mods in production scenarios, one limitation keeps surfacing over and over:

Mods operate on a materialized data view, while native visuals operate on top of Spotfire’s semantic layer.

This difference might seem subtle, but it has major practical consequences.

Native visuals have access to:

• Measure definitions (Sum, Avg, etc.)

• Aliases (e.g., Sum(A) → sumX)

• Synthetic constructs like <Column Names> / <Measure Names>

• Implicit wide-to-long transformations

• Axis semantics and hierarchy context

Mods, in contrast, only receive:

• A flattened DataView

• Explicit columns only

• No measure metadata

• No knowledge of how values were derived

This creates several concrete limitations:

1. Multi-measure visuals are harder than they should be

   In native visuals, multiple measures can be dynamically grouped using <Column Names>.

   In Mods, this concept does not exist. Developers must manually pivot/unpivot data just to simulate something the engine already knows.

2. No access to measure aliases or metadata

   If I define Sum(A) as “sumX”, that name is usable in native visuals but completely invisible to Mods.

   There is no way to dynamically bind or group measures based on their semantic definition.

3. Loss of aggregation context

   Mods cannot access whether a value is a Sum, Avg, or custom expression.

   They also cannot access hierarchy or drill context in a meaningful way.

4. Axis configuration is purely column-based

   No binding to expressions, measure groups, or metadata-driven constructs.

   Everything must be pre-shaped into physical columns.

5. Increased data engineering overhead

   To replicate native behavior, users are forced to:

• Reshape data (wide → long)

• Duplicate logic already defined in visuals

• Maintain parallel structures just to support Mods

At this point, Mods are not just “less convenient” — they require a fundamentally different modeling approach.

The core issue is not visualization capability, but lack of access to the semantic layer that already exists in Spotfire.

Suggested improvements:

• Expose measure metadata (name, alias, expression)

• Provide an equivalent to <Column Names> / <Measure Names> in Mods

• Expose aggregation and axis semantics

• Optionally allow Mods to consume a pre-aggregation / semantic view instead of only the flattened DataView

Mods are a powerful extension mechanism, but today they operate one layer too late in the pipeline.

Bringing them closer to the semantic model would significantly reduce complexity, eliminate redundant data shaping, and unlock much more advanced use cases.

If Mods are meant to be a first-class visualization layer, they need access to the same constructs that make native visuals powerful.