Reverse attribute mapping..

[Rod Widdowson]

> I think your example there is off. If you have two AttributeDefinitions
> encoding to the same SAML, you still have to give them a separate id.
> Having two id="eduPersonAssurance" doesn't work, I don't think. Am I
> wrong?

This works because (for reasons I have not yet complete grocked yet)
p:id="eduPersonAssurance" just sets the identifier that we maintain, it does
*not* affect the Spring id - which I chose not to specify because the beans
are embedded, but would be id="springId".  This ties in to the aliases
question below.
  
> >I checked this in to svn under
>
>idp-attribute-filter-spring:src/test/resources/net/shibboleth/attribute/ma
> >pp
> >er/attributesmapper.xml
> 
> What's the difference between the two files there?

One was detritus left from early testing which should not have been checked
in (indeed Eclipse didn't think that I had).

> 
> You mean where it says 	p:id="eduPersonAssurance" ?

Indeed.

> Yes, I wouldn't call the property aliases, I'd just call it attributeIDs
> or some such.

I'll make that change then.

> 
> >3) Otherwise it hangs together reasonably sensibly.
> 
> Can a bean property (valueMapper) be shorthanded? Or were you just
> comparing syntaxes there?
[...]
> Also, can a property like that be defaulted? Can we default to
> StringAttributeValueMapper?
> 
[...]
> Is there a shorthand for specifying lists?

I have no idea, but I shall find out and report back.

> >4) I am still intending spending some time to see whether it is possible
> >to
> >create a system to map from the attribute filtering engine to this
> >configuration.
> 
> You mean resolver engine?

Yes.

Thanks

Rod