[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 28th August 2013
Meeting Minutes 28th August 2013
Attendees:
Software AG, Inc. Bhaskar Reddy Byreddy Member
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Bhaskar assumes scribe duties.
Rollcall: 8 of 13 (61%) , meeting is quorate
Agenda: no objections for accepting the agenda as posted.
Minutes:
21st August 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201308/msg00066.html
MOTION: m: Adrian, s: Gil: I move to accept https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201308/msg00066.html as minutes for Aug 21.
no discussions and objections
Minutes approved
Administrivia:
CloudPlugFest: unlikely to have any TC representation in Madrid
MOTION: m:Gil, s: Tom: appoint Adrian as pro tem TC chair for next two weeks (2nd thru 13th September 2013)
Martin to ensure Adrian has correct kavi privileges.
Passed w/o
Editing Team Update:
Use of kavi - "CSD Branches" and kavi revisions: Martin checked with TC Admin
... no best rules or best practice apart from not using "revision" numbers in working drafts (since a wd number is a revision number)
.... so no more wd20-r1, just do wd21 - even for trivial editorial changes
..... proposal is to keep the "CD Branch" approach proposed by editors, and in addition to add a link to each WD file in the working darfts directory.
Adrian Otto (Rackspace): WRT revisions in Kavi for working drafts, I agree with the approach to have a link at the top level of the folder.
Adrian Otto (Rackspace): and use kavi to catalog the revisions
Adrian Otto (Rackspace): noted, we will not make numbering revisions
CAMP-71 resolution applied in the CD-4 branch (wd22)
Adrian Otto (Rackspace): we should add a link to WD22 for the minutes in the Editor's Update section: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50420/camp-spec-v1.1-wd22.doc
Jacques can a brief into to latest Test Assertion WD: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201308/msg00077.html
New issues:
Public Review issue https://tools.oasis-open.org/issues/browse/CAMP-84
Motion to open the issue CAMP-84; m-Gil; s-Adrian
no objections/discussions; CAMP-84 opened
Adrian Otto (Rackspace): I added my comment to CAMP-84
Issue Discussion:
Jacques had posted an update to CAMP-83: https://www.oasis-open.org/apps/org/workgroup/camp/document.php?document_id=50471
However part of the proposal covers https://tools.oasis-open.org/issues/browse/CAMP-51 1.7 Notational Conventions
@Jacques: proposal is to use the wording "resource" instead of "resource instance" as resource is the instance of a template
Jacques (Fujitsu): "The term resource is understood as an addressable instance of a resource type as described in Section 5. For example, an AssemblyTemplate resource means an actual addressable data item of type AssemblyTemplate, i.e. that satisfies the definition and serialization rules of AssemblyTemplate. "
Alex Heneveld (scribe): good observation about confusion. +1 resource has a well-understood meaning in the REST world. however we need clarity between "templates" (which are represented as REST resources) and the "instances" (= "components" and "assemblies", which are also represented as REST resources).
Tom Rutt (Fujitsu): assembly is a resource instantiated USING an assembly template
Alex Heneveld (scribe): @Gil - don't quite understand ... assemblies are instantiated from assembly templates, right?
Alex Heneveld (scribe): but agree we should not say "assembly is an instance of assembly template"
Adrian Otto (Rackspace): Alex, no they are not
Adrian Otto (Rackspace): they are created using the plan in the template
Adrian Otto (Rackspace): but they are not an instance of a template resource whatsoever
Adrian Otto (Rackspace): the Assembly Template is a specification for an Assembly Resource
Alex Heneveld (scribe): @Adrian -- would you agree that Assembly instances are instantiated _based on_ AssemblyTemplate resources ?
Adrian Otto (Rackspace): yes
Adrian Otto (Rackspace): but not in the sense of a class relationship
Adrian Otto (Rackspace): they are different classes that represent different things
Jacques (Fujitsu): use "generated" instead of "instantiated"
Alex Heneveld (scribe): +1
MartinC: +1 to adrian
Alex Heneveld (scribe): +! avoid "instan*" not because it is wrong but because it will be misunderstood by OO people
Alex Heneveld (scribe): -1 realise (or "realize" even) -- again i agree it is correct, but it will be misundersood vs "created from"
Adrian Otto (Rackspace): We should submit a new issue for the terminology.
Jacques (Fujitsu): +1 to realize a Template
Adrian Otto (Rackspace): Created from, generated from, realized from
generated/created from/realize vote for one word
Star poll: please click the Vote button to cast your ballot:
what words are best for the relationship between a component and a template?
(1) generated from
(2) created from
(3) realized from
(4) instantiated from
(5) realized using
This is a multiple-choice vote.
Alex Heneveld (scribe) voted for: generated from,created from
Adrian Otto (Rackspace) voted for: created from
MartinC voted for: generated from,created from,realized using
Tom Rutt (Fujitsu) voted for: realized using
Bhaskar Reddy (Software AG)1 voted for: generated from,created from
Jacques (Fujitsu) voted for: generated from,realized from,realized using
Gil (HTML) voted for: generated from
Mark C voted for: realized from,realized using (submitted by: MartinC)
Results:
what words are best for the relationship between a component and a template?
Tally Choice
5 generated from
4 created from
2 realized from
0 instantiated from
4 realized using
0 Abstains
Gil Pilz (Oracle): let's alternate them evenly throughout the doc
Alex Heneveld (scribe): +1 Gil -- any of the top 3 are fine -- generated / created / realized
Alex Heneveld (scribe): but NOT instantiated
No clear conclusion apart from not using instantiated!
With respect to the pseudo notation part alex proposed adding the following:
* An expression in italics indicates any value can be substituted there, and it must be consistent with the type indicated by the word in italis
* "[]" in such an expression indicates a list of the type indicated by the expression preceding it
* Angle brackets ("<" and ">") surrounding such an expression indicates that the type shall be as specified by another field in the object, or other context information (this is rare but is used e.g. in 5.28 Sensor resource, where something shall be of "<sensorType>" and "sensorType" is another field in the object)
* "..." indicates that text is omitted, e.g. for brevity
Alex Heneveld (scribe): (augment the proposed JSON schema -- posted at issue 51)
https://tools.oasis-open.org/issues/browse/CAMP-83
Discussion on normative statement PDP-20
Tom Rutt (Fujitsu): order significance is not testable without api probes
Jacques (Fujitsu): Providers SHALL NOT regard the order of the ArtifactSpecifications within this array as semantically significant. [PDP-20]
Adrian Otto (Rackspace): Dropping the normative statement is a step backward for interop. Let's aim to make changes that improve portability of applications.
Gil Pilz (Oracle): "This specification is deliberately silent on the significance, if any, of the order of the ArtifactSpecifications in this array."
Alex Heneveld (scribe): -1 @Gil order should not be significant, that is inviting interop issues
MartinC1: thats worse gil, that implies other specs might put a significance on order
Alex Heneveld (scribe): revisiting Martin's suggestion, the statement _as written_ can be tested by sending a spec in various orders and asserting we get a valid result
Gil Pilz (Oracle): Martin - i agree that other specs can put significance on the order
Gil Pilz (Oracle): i would encourage an orchestration spec that wanted to use CAMP to do exactly that
Jacques (Fujitsu): +1 to composability of CAMP with other (orchestration) specs: you do not want to preclude other specs to *profile* CAMP by putting significance on the order.
AOB
Stragglers: none
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]