"sourceAttributeID was not specified but is required"

[Cantor, Scott]

> Are there definitions that don't require a source attribute?

Yes, Template is an example that doesn't, since it doesn't intrinsically pull a specific attribute out. You tell it explicitly what it will be reading from, so that bypasses the constraints of the broken "one source ID" limitation the schema has.

There are a few others like that, Script is another.

Anything that inherently infers a source ID if one isn't provided is an example that breaks under particular assumptions so we warn if there isn't one supplied. Simple/Scoped, a few others.

> Rather than have one giant mapped attribute that could calculate ePSA, we
> currently have campus specific mapped attributes that are aggregated under
> ePSA:

I have a similar example. But that only works unambiguously if each dependency supplies exactly one input. Since that isn't covered by the configuration, it's inherently working "accidentally" and that's what the warning is about.

> It made sense at the time we did it.
> Do we live with the warning? Are there more appropriate attribute types?

Other than a script I don't think there's any way to model that use case today given the flawed design that's been in place since V2 was first shipped. As long as the source ID is specified on the top level and not the individual dependency, it can't be correctly expressed. It will work if the inputs stay within a set of unspecified boundaries and break if they don't.

-- Scott