scripting the resolver with Velocity "Template" attribute defintion

[Cantor, Scott]

On 2/15/17, 7:01 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:

> Hmmm.  I couldn't remember exactly how the template attribute def works with multiple dependencies, so I went and
> read the code.  I think I'd make a slightly different proposal: That the current implementation just doesn't make any
> practical sense for the case of multiple dependencies with multiple values.

I think it really depends what one's mental model happens to be. I could see it applying the SourceAttribute settings to two independent DataConnector inputs, one after the other. I don't think it does currently, but that's as plausible as any other interpretation would be.

So I do think it's totally undefined, and it probably shouldn't currently even allow it in the case of DataConnectors, which is all connected (sic) to Rod's work ongoing to replace Dependency with explicit inputs that are either AttributeDefs or DataConnectors, at which point one could impose specific rules about what's allowed.

> It's fine if you've got just 1 dependency (with either 1 or many values).  It's also fine if you've got multiple dependencies
> with 1 value each (or maybe *at most* 1 value each).

I would imagine it works if you have 5 input attribute definitions that supply material for 5 SourceAttribute expressions and all have the same value count. At least, I would think it might.

> But the multiple dependencies with multiple values case seems an issue to me.  Say you have dependency d1 with values
> (foo, bar, baz), and d2 with (x, y, z), with each set of values in that iteration order.  As near as I can tell, the template is
> going to get executed 3 times, with the following values:
>
> (foo, x)
> (bar, y)
> (baz, z)

I think that's the case I allude to above. And I would contend that's sensible if it's what your mental picture happens to be. It makes more sense for AttributeDefs than DataConnectors.

> Since the value ordering is arbitrary, that doesn't seem very useful.

It's not arbitrary. Attributes are an ordered set of values, very explicitly. We actually broke that pre-3.0 until I caught it and realized what we'd done. The reason of course is modeling SQL result sets out of DataConnectors, maintaining NULL values inside those sets, etc.

> Thoughts? 

I think virtually anything might be possible or useful, but once Rod has blown Dependency to the hellpit it belongs in, we have a shot at actually controlling what's actually possible to specify.

-- Scott