Metadata support: Extensions handling

[Brent Putman]

On 8/14/13 4:50 AM, Ian Young wrote:
>> The only thing about that impl is that it is append-only,
>> other than a clear() op.  Implementing a remove() op etc might be tricky
>> with all the class and interface indexing going on though, but I may
>> give it a shot.
> The way I was thinking about how to build the inherited contexts / metadata wouldn't require remove().  

Probably not, but since this is a general new mechanism being added to
the XMLObject interface, I think supporting remove ops would be a good
thing, if possible.


> I'm also not sure that you need the multi-map behaviour for this, and in practice a ClassIndexedSet seems as if it would be sufficient. 

For specific cases, having it be a regular single-valued map might be ok
ala ClassIndexedSet, but again, since this is a new general capability
being added to XMLObject, I'm trying to think more broadly than the
immediate use case, esp since it has interface implications and we'd be
locked into the choice until at least the next major version.


>  For example, for the KeyAuthority case the object would contain the processed form of all the individual key authorities from all levels in the hierarchy, which allows you to do things like maintain an index to them to help with finding the right one when you need it.

Well, actually, in that specific example, IIRC each KeyAuthority gets
turned into a distinct instance of PKIXValidationInfo. So a multi-map
actually works better there.  Similar with KeyInfo - depending on its
contents it can be processed into more than one Credential.  Of course
we could have a container type thing for those, holding multiples, and
then store the single container instance on the XMLObject.  But that
seems a lot more complicated, and less nice to use, than just making it
a multi-map in the first place.

> "item metadata" was where Chad and I ended up for the class-indexed stuff attached to an Item in the MDA framework, so that would be consistent. 

Yeah, I got the idea from there, with "item" -> "object".  :-)

I guess really it's just one method name on XMLObject, so if we later
come up with the Name To Shame All Other Names, we can always change it
up until we release.