OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [camp] Need to refine 5.9.13 in camp-spec-v1.1-wd32-issue44rev4.doc uploaded

I think we need to be clear about the use cases with regards to our metadata and multiple inheritance. IMO "Consumer validates correctness of Providers resource model" is the least likely of all the use cases in this area. A human Consumer will consult the metadata to figure out how to write code that consumes the resources that are described by that metadata. A programatic Consumer will consult the metadata to figure out how to display the information in a resource to a human who, one would hope, will have enough context to understand the semantics of the information being displayed. The point of defining rules around multiple inheritance is to allow people to write client code that, if it is working with a CAMP-compliant provider, won't break. It's not the Consumers job to figure out if and/or why it is breaking (or would break) when dealing with a Provider that breaks these rules.

All lot this is a long-winded way of saying, I think flattening the map of attributes for every resource type has some advantages - the chief of which is that it makes things simpler for the Consumer. However, it does make things more difficult for the Provider, especially in cases where the Provider is supporting a complicated set of inherited resources.

~ gp

On Dec 18, 2013, at 2:15 PM, Tom Rutt <TRutt@us.fujitsu.com> wrote:

Just a few clarifications of my concerns below
From: camp@lists.oasis-open.org [camp@lists.oasis-open.org] On Behalf Of Tom Rutt [TRutt@us.fujitsu.com]
Sent: Wednesday, December 18, 2013 11:08 PM
To: Anish Karmarkar; camp@lists.oasis-open.org
Subject: [camp] Need to refine 5.9.13 in  camp-spec-v1.1-wd32-issue44rev4.doc uploaded

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
<or multiple inheritance when there are no colliding attribute names across the transitive closure of inherited supertypes>.

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.
<appears in more than one of the sypertypes that the 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.

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

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]