kmip-interop-tech — archive

[Jim Flood]

Ok then, I see what you mean. In that case, you put the contributing attributes into the Template of the Register's Request Payload, after which you cannot add, modify or delete from this set without destroying and re-creating the template. Then it could be clear that an attribute outside of the Template applies the the managed object -- the template -- itself, for example, a Name attribute. The reason Name is not allowed as part of the template value comes from the fact that names must be unique, and so a template can't assign the same Name over and over again, and not for any other special reason. Therefore, Name cannot be included inside the Template (of the Register's Request Payload.) Furthermore, I would argue that Get Attributes would not see any of these attributes passed in the Template of the Register. Get Attributes would only return Name, Initial Date, etc. -- those attributes of the template-as-a-managed-object. Get/Modify/Delete Attributes would be oblivious to the contributing attributes -- those part of the immutable value of the template. This would let you manage the templates themselves with attributes such as Object Group, Contact Information, etc., and the only way you could view the contribution of a template is to Get the template and see what was returned. I'm not sure which is easier to explain to end users -- the difference between all of the attributes of the template or the difference is how Get/Delete/Modify Attribute work against a template , i.e. how I understood the spec (and implemented it) vs. how you are describing it. I am lazily in favor of the former vs. the latter, simply to avoid the work involved in changing my implementation, which is not to say that I disagree with your description. Jim Flood On 9/4/2012 2:45 PM, Tim Hudson wrote: On 5/09/2012 6:37 AM, Jim Flood wrote: * SHALL the Name attribute of the Template be passed in the Template Attribute of the Register Request Payload, rather than the Template itself? My view is that the Name should be passed in the Template Attribute in Attribute format. However there is a use case (test case) which does this differently - something which I think should be fixed. * SHALL the attributes of the Template that contribute to created objects (later, in subsequent operations) be passed in the Template object of the Register's Request Payload, OR, can they also be specified in the Template Attribute? (I prefer the latter to be consistent with Create.) My view is that the first is the logical option. Attributes contributed to other objects must be specified in the Template structure. However the specification allows for the usual inheritance from other templates and from the template attribute list - but those I think can reasonably be interpreted as applying the the template object and not to contributing to the 'value' of the template. That interpretation I do not think is precluded by the specification. Consistency with Create would argue that anything specified in Register for attributes are attributes of the object itself and not the value - i.e. those items in TemplateAttribute are for the template itself and only those items in the Template structure apply to created objects. I keep coming back to None of the client-settable attributes specified in a Template except the Name attribute apply to the template object itself, but instead apply to any object created using the Template. That to me always made it clear the attributes being contributed to objects came in the Template structure. Mixing up the other attributes which apply to the template object leads to all manner of confusion. Tim.