Metadata support: Extensions handling

[Ian Young]

On 13 Aug 2013, at 23:08, Brent Putman <putmanb at georgetown.edu> wrote:

> I was just looking at the
> ClassToInstanceMultiMap in aggregator-pipeline.  We may be able to use
> as-is and I'll probably promote that, or a variant of it, up to
> java-support.

I've considered the same thing, it seems like it would be generally useful and it's certainly not MDA-specific.  I think its just in aggregator-pipeline because it pre-dates java-support.

> 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().  If you're creating a new context from the parent one, you get the equivalent of remove() by not copying across particular items from the parent context.

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 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.

> The main headache there is deciding what to call the damn collection
> thingy.  "annotations" and "metadata" are what come to mind, but of
> course both those terms are overloaded in our world. At the moment I'm
> considering using "object metadata", so XMLObjects will get a new
> getObjectMetadata().  Unless someone has a better name.

"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.  I seem to recall we had a couple of false starts before getting there, and it's still a source of occasional confusion.  Kudos to anyone who can come up with something better.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130814/fbe67dc1/attachment.bin