Attribute Dictionary & V4.0

[Rod Widdowson]

Rather than continue to hijack Peter's thread, I'll move to a new one.  The context starts here

Me:
> > I guess that the end goal is that the deployer "just" defines a few attributes
> > with well known names and the Federation supplied information controls the
> > rest (encoding, display, filtering and so on).
> 

Scott:

> The basic idea is to provide a separate recipe for as many attributes and their metadata as possible, 
> and then just "connect" up the attributes from the resolver with those definitions, either by assuming
> the IDs line up by convention or by just attaching the ID to the attribute in the resolver some how 
> that's not confusing. I haven't really worked it out beyond the general idea that anything that's
> currently "inside" the <AttributeDefinition> element at the top level would be something we'd 
> want to factor out.

I was thinking about this this morning and at the risk of stating the blindingly obvious what is needed is an
AttributeDictionaryService which "does the usual" with respect to a new AttributeDictionary Interface.  This can initially be
implemented either by the AttributeResolverImpl Service or (perhaps better) by a shim service which takes the
AttributeResolverService as a parameter.

So "all" we need to do in V4.0.0 is to define precisely what the AttributeDictionary does.  A start point will be "resolvers for
everything currently inside the AttributeDefinition".

There's obvious a bit of work to turn the attribute resolvers inside out like that and the rewire the encoders and UI components to
the new service, but we would then be in a position to plug in a completely different service which looks at a "real Dictionary" and
think about pensioning off non relevant parts of the AttributeDefintion language.

What's not obvious to me is how we wide this Interface in V4 without changing the API.  It doesn't seem to me that the new java
support will help here, but I also suspect that when we have the need the mechanism will become obvious.  Worst case we need to have
two different service interfaces and have our implementation implement both.

Rod