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: Draft Minutes 28th August 2013

Meeting Minutes 28th August 2013


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


       Bhaskar assumes scribe duties.

       Rollcall:  8 of 13 (61%) , meeting is quorate

      Agenda: no objections for accepting the agenda as posted.

      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 

             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)
          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)


    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.


      Stragglers: none

Meeting adjourned

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