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


Alex:
Clarifying the question.
Are you asking whether a subtype that inherits an attribute
can rule that its value is always NULL?  I believe the answer is yes.

Don't understand your question about lists.  Pl.rephrase in terms
of inheritance.
All the best, Ashok

On 1/7/2014 4:37 PM, McDonald, Alex wrote:

(Apologies for duplicates to Gilbert; email problems on the list)

 

Can the provider delete an attribute? Or is (JSON)

 

″attribute″ : null

 

sufficient and equivalent? What about lists? Are they concatenated, merged or replaced?

 

Alex McDonald

Standards & Industry Associations Group

CTO Office

NetApp

+44 7795 046686 Mobile Phone

alexmc@netapp.com

twitter: @alextangent

Follow us: Description: Description: FacebookDescription: Description: TwitterDescription: Description: Linked InDescription: Description: YouTubeDescription: Description: SlideshareDescription: Description: Community

 

 

From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Gilbert Pilz
Sent: 07 January 2014 18:53
To: camp@lists.oasis-open.org
Subject: Re: [camp] Need to refine 5.9.13 in camp-spec-v1.1-wd32-issue44rev4.doc uploaded

 

I don't see the problem with identically named attributes. A Provider either does the correct thing, or they don't. In this case "the correct thing" is to (a) make sure the identically named attributes have the same data type, (b) make sure the implementation of the resource honors all the semantics defined by the super types. It is not the Consumer's job to verify any of this - the Consumer should just assume the Provider is doing their job.

 

~ gp

 

On Jan 7, 2014, at 10:41 AM, Gilbert Pilz <gilbert.pilz@oracle.com> wrote:



Forwarding for Alex McDonald …

 

Begin forwarded message:



From: "McDonald, Alex" <Alex.Mcdonald@netapp.com>

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

Date: January 7, 2014 6:26:52 AM PST

 

Second the observations. The provider’s issues or difficulties are secondary to consumer correctness and predictability.

 

While flattening provides most of the relief, there is still the issue of identically named attributes. Semantic checks on the content is a complete no-no. What would you recommend?

 

Alex McDonald

Standards & Industry Associations Group

CTO Office

NetApp

+44 7795 046686 Mobile Phone

twitter: @alextangent

 

 

From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On Behalf Of Gilbert Pilz
Sent: 07 January 2014 01:04
To: camp@lists.oasis-open.org
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.


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



---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 

 




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