[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 29th January 2014
CAMP TC Meeting Minutes 29th January 2014
Attendees
US Department of Defense (DoD) Michael Behrens Member
Software AG, Inc. Bhaskar Reddy Byreddy Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Scribe: Anish Karmarkar
Chair: Martin Chapman
Date: 2014-01-29
Topic: Roll
Quorate, 10 of 12 (83%)
Topic: Agenda bashing
No comments
agenda approved w/o
Topic: approval of minutes 2014-01-22
https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201401/msg00057.html
no comments on those minutes
motion: m:adrian s:anish moves to approve minutes of 2014-01-22 located at https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201401/msg00057.html
motion approved w/o
Topic: Administrivia
Martin away next week need a pro tem chair
Adrian volunteered to be the pro tem chair
motion: m:ashok s:anish Adrian to be the co-chair for the week of 2014-02-03
motion approved w/o
Topic: disposition of PR comments
Martin has run the JIRA report on PR comments and hand edited it
See https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201401/msg00070.html
Tom: do we have a requirement to send email to PR reviewers?
Martin: no we don't have a requirement, but we decided to send emails to a few
... checked with TC admin on this, and he is ok w/ my report
... I'll attempt to go thru and respond to all the ones that have email addresses
Adrian: new rules in 2013 that require that we respond
Martin: process requires an ack and we have done that
martin to respond to non-TC members who commented
Martin to publish the final document by friday, comments to be sent before thursday. Friday's doc will be final.
martin: this has to be part of the package (zip) that is approved for the next PR
ACTION: gil to look over martin's disposition of comments by thursday
Topic: timelines
2 p2 and 2 p3 issues open
Topic: ed team update
WD37 applies resolutions for issues 156, 158, 160, 161
TA WD16:
Jacques: incremental upgrade
updates for various test assertions that update been updated as a result of issue resolutions
Jacques: few things to do such as copying the normative stmt itself (easier to read, this is editorial)
... need to add test targets for plan, pdp
... right now it targets messages
... will wrap up by next week
Tom: for the ones that are not testable: is it only m01 and m04?
jacques: there may be one or two more that are about the metamodel
... need to make a stmt about which mandatory stmts have TA and which don't
Tom: do u have a TA for attributes about supertypes
jacques: need to know the tag to answer that
Martin: are you confident that you won't be requesting material changes to the main spec
Jacques: yes
do u think we should do the PR of the two documents together?
Jacques: would like some overlap
Topic: issue 159
https://tools.oasis-open.org/issues/browse/CAMP-159 two ways to extend a resource type with additional attributes?
Discussion in JIRA
Gil: i raised this issue. there has been some discussion on this. Why do we have two ways of doing things? I asked for usecases for that.
... tom had a related issue about extension without new type and how it affects subtypes
... the spec says that subtypes inherits everything
... one use case is extension of the camp_resource itself
... this allows addition of attributes to all types -- very convenient
... I believe there are valid reasons for adding additional attributes in two different ways
... willing to CNA this
Tom: happy with CNA
Martin: me2, should encourage subtypes, but valid reasons not to. Perhaps primer material
Jacques: may be add some explanation in the spec
... or leave it to the primer
Tom: is it clear that extension attribute from supertype is inherited
Gil: it is clear
motion: m:gil s:tom close issue 159 with no action
motion approved w/o
Gil Pilz (Oracle): Tom we say "When a resource type (sub-type) inherits from another resource type (super-type), the sub-type inherits, and therefore includes, all the super-types attributes along with its constraints and semantics."
Topic: issue 146
proposed CNA, if we don't get a proposal by next week we should CNA
martin: alex said that he won't have time but he won't stand in way of closing it
Topic: issue 153
https://tools.oasis-open.org/issues/browse/CAMP-153 Two approaches to identify services in a DP?
Concrete Proposal needed
Adrian: thought we would eliminate a redundancy. While trying to craft a proposal realized that there is a good reason to have two ways to do this
From Adrian's JIRA comment:
Currently both of these formats are legal. Upon filing this issue, I felt that having two ways of doing the same thing would lead to additional complexity in the spec and related implementations. However, there is a good reason for having two expressions of this. It's a way to hint to the model interpreter that there should be ONE instance of the service used by multiple artifacts. That's why using a fulfillment id makes sense. When you want MULTIPLE instances of the service, you can list them individually. That use case justifies both of the formats.
I plan to move to CNA.
motion: m:adrian s:gil close issue 153 with no action
motion approved w/o
Topic: issue 63
https://tools.oasis-open.org/issues/browse/CAMP-63 TypeDefinitions for CAMP-defined types
zip file in JIRA - Need a link from spec cover page...
Martin: this is a housekeeping issue
gil: i updated the latest version of JSON file
... martin was kind enuf to review these
... he saw 'nCamp' in one of the files, which needs to be fixed
gil: martin was looking at an old version that had camelCase in it
martin reviews the latest and it does not have the problem
Gil: these are real json objects. the URIs are self-consistent
... use relative URIs
... as far as I know they are all consistent
... tested it on nCamp
Martin: what is it useable for?
for someone who is implementing CAMP on the provider side can just use it and hack it as necessary discussion on what to call it
Tom: relative URIs are good. don't worry about it
Martin: we should add a link and text in the 'related artifacts' section on the coverpage that points to this
Gil Pilz (Oracle): If the array is non-empty, for every resource type that the Platform supports, there SHALL be a type_definition resource Link that represents such a resource type.
Martin kvetches about 'metadata' as the description for this
call it CAMP Type Definitions
MartinC: camp-spec-typedefs.zip
Gil: can't resolved this issue till everything is ready
wordsmithing text...
Gil Pilz (Oracle): Append to the end of Section 5.18.1 (type_definition_links):
Gil Pilz (Oracle): "To help developers in supporting this requirement, a package containing the type_definition_resource resources for every resource defined in this specification
"To help developers in supporting this requirement, a package containing the types defined in this specification ..."
Gil Pilz (Oracle): "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as part of this specification."
Gil Pilz (Oracle): "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as an auxiliary to this specification."
Gil Pilz (Oracle): To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as a non-normative auxiliary to this specification."
Gil Pilz (Oracle): "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as a non-normative auxiliary artifact."
Ashok Malhotra (Oracle): change auxiliary to appendix?
MartinC: This prose specification is one component of a Work Product that also includes a non-normative auxiliary file: http://docs.oasis-open.org/camp/camp-spec/v1.1/camp-type-definitions.zip
MartinC: this above for the cover prose for Additional artifacts:
MartinC: on the cover page add the following text to Additional artifacts:
MartinC: This prose specification is one component of a Work Product that also includes a non-normative auxiliary file: http://docs.oasis-open.org/camp/camp-spec/v1.1/camp-type-definitions.zip
MartinC: and at the end of section 5.18.1 of wd37 add the following:
MartinC: "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as a non-normative auxiliary artifact."
MartinC: "To help developers in supporting this requirement, a package containing the type_definition resources for every resource defined in this specification is included as a non-normative auxiliary file."
above text added to proposal in JIRA
motion: m:gil s:tom resolve 63 with proposal in JIRA
motion approved w/o
ACTION: Editors to add an appropriate "Related Work" reference to the TA document on the cover page.
AOB:
Stragglers: None
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]