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
twitter:
@alextangent
Follow
us:
From:
[mailto:]
On Behalf Of Gilbert Pilz
Sent: 07 January 2014 18:53
To:
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 <>
wrote:
Forwarding for Alex McDonald …
Begin forwarded message:
From:
"McDonald,
Alex" <>
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
To:
Gilbert
Pilz <>,
""
<>
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
Follow
us: <image001.png><image002.png><image003.png><image004.png><image005.png><image006.png>
From:
[mailto:] On
Behalf Of Gilbert
Pilz
Sent: 07
January 2014 01:04
To:
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 <>
wrote:
Just a few
clarifications of my concerns below
________________________________________
From: []
On Behalf Of Tom Rutt []
Sent: Wednesday, December 18, 2013 11:08
PM
To: Anish Karmarkar;
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: []
On Behalf Of Anish Karmarkar []
Sent: Wednesday, December 18, 2013 8:34
PM
To:
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