Need to refine 5.9.13 in camp-spec-v1.1-wd32-issue44rev4.doc uploaded

[Tom Rutt <TRutt@us.fujitsu.com>]

given the current Rev4 Text for the issue resolution,  we need to add some clarification to 5.9.13 to explain what happens to this attribute_definitions_links attribute of type_definition resource when inherited_from has more than one link.


"
5.9.13  attribute_definition_links
Type: Link[]
Required: true
Mutable: false
This attribute contains an array of Links. Each Link in this array points to an attribute_definition resource. Each of these attribute_definition resources represents an attribute of the type represented by the Type resource. For every attribute of the type not inherited from its super-types, there SHALL be an attribute_definition resource Link that represents the attribute. [RE-45] For more information on the attribute_definition resource see the next Section.
"
This subclause states that only the non inherited attributeDefinitions are pointed at by the link array.

Thus as currently specified, any additional constraints on an attribute's semantics added by a subtype inheriting that attribute from a supertype,
 must be recorded in the documentation attribute of the type_definition resource, not the attributeDefinition resouirce, since the inherited attributes are not pointed at by the subtype's attribute_definition_links attribute.

This causes no problem for single inheritance.

However, for multiple inheritance (i.e., more than one inherited_from link in the inherited_from link array of the type_definition resource) when determining the transitive closure of attributes for a subtype resource, any serialization of that subtype resource must only include one instance of the any attribute whose name appears in any of the superTypes that type inherits from.  

If the attribute_type definitions in each of the multiply inherited supertypes having a common attribute name are compatible, this would not cause a problem if the
server implementation treats the "collided" attributes just as if they were inherited from a diamond inheritance tree.


An alternative would be to change the specification of 5.9.13 to have it be a flattened list of attribute_definition s, reflecting the transitive closure from all the inherited supertypes.  However, this would require the specification to include rules for which attribute definition would be pointed at by the multiply inherited subtype with colliding supertype attributes.    In particular, flattened lists would allow the additional attribute constraints to be included in the definitions link for each inherited attribute in the subtype's list. I think this would add much more complexity to the spec, and would have to be justified.


Tom
________________________________________
From: camp@lists.oasis-open.org [camp@lists.oasis-open.org] On Behalf Of Anish Karmarkar [Anish.Karmarkar@oracle.com]
Sent: Wednesday, December 18, 2013 8:34 PM
To: camp@lists.oasis-open.org
Subject: [camp] Groups - camp-spec-v1.1-wd32-issue44rev4.doc uploaded

Document Name: camp-spec-v1.1-wd32-issue44rev4.doc<https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=51799>
________________________________
No description provided.
Download Latest Revision<https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51799/latest/camp-spec-v1.1-wd32-issue44rev4.doc>
Public Download Link<https://www.oasis-open.org/committees/document.php?document_id=51799&wg_abbrev=camp>
________________________________
Submitter: Dr. Anish Karmarkar
Group: OASIS Cloud Application Management for Platforms (CAMP) TC
Folder: Proposals
Date submitted: 2013-12-18 11:34:19