Metadata support: Extensions handling

[Ian Young]

On 15 Aug 2013, at 21:01, Brent Putman <putmanb at georgetown.edu> wrote:

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

If it's going to be that generally available, I agree that it makes sense for it to be more general.

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

Again, agreed.  I hadn't realised we were talking about something that would be part of XMLObject.

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

That's a design choice too, of course.  Personally, having a single "trust context" that knew about all of the trust material that was in scope would make more sense to me, but if you've already made the decision that the person processing the node needs to do the enumeration then that's moot.

	-- 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/20130815/a3f47e82/attachment.bin