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] Draft Minutes 12th December 2012


One correction in-line:

On Dec 12, 2012, at 1:29 PM, Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM>
 wrote:

> Attendees:
> 
> Carlson, Mark	 		Oracle					Voting Member
> Chapman, Martin		Oracle					Chair
> Durand, Jacques		Fujitsu Limited			Voting Member
> Heneveld, Alex		Cloudsoft Corporation Limited	Member
> Janssen, Gershon		Individual				Voting Member
> Johnston-Watt, Duncan	Cloudsoft Corporation Limited	Member
> Karmarkar, Anish		Oracle					Voting Member
> Kunze, Tobias			Red Hat				Voting Member
> Luster, Eugene		US Department of Defense (DoD)	Member 	(gains voting after this meeting)
> Malhotra, Ashok		Oracle					Voting Member
> Miller, Rich			Cloudsoft Corporation Limited	Voting Member
> Mischkinsky, Jeff		Oracle					Voting Member
> Otto, Adrian			Rackspace Hosting, Inc.		Secretary
> Pilz, Gilbert			Oracle					Voting Member
> Song, Zhexuan			Huawei Technologies Co., Ltd.	Voting Member
> Tupitza, Charles		JumpSoft				Voting Member
> Yendluri, Prasad		Software AG, Inc.			Voting Member
> 
> Intro:
> 
>  Jacques Durand assumes scribe duties.
> 
>  Roll call. Meeting is quorate 14 of 18, 77%.
> 
>  Agenda: add update from editors.  
>     agenda adopted w/o
> 
> Minutes:
> 
> 
>  5th December 2012: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201212/msg00026.html 
>  MOTION: Gil to adopt minutes Dec 5th, Adrian 2nd. No discuss. passes UNAN
> 
> Administrivia:
> 
>   Adrian confirms Rackspace will host the next F2F in San Antonio, TX, 22-25 Jan 2013

Should read:

"Adrian confirms Rackspace will host the next F2F in San Antonio, TX, 23-25 Jan 2013"

>   ... please gives notice attendance to Adrian (name + email + title) by COB
> 
> Editors Update:
> 
>   Anish: editors generated WD #1, available in WD folder - just formatted initial contribution in OASIS template.
>   ... no change in content. No content received so far.
>   ... always use the latest draft # for any comment.
>   ... Editors look into JIRA for whatever issue is resolved, and moves the resolution to latest draft.
>   ... rev history tells what issue is in.
> 
> New Issues: 
> 
>    https://tools.oasis-open.org/issues/browse/CAMP-35 Spec needs to clarify the constraints on the relationship between Assembly Templates and Application Component Templates
> 
>   gil: based on implementation of #24. Relationship between Assemble template and app component template.
>   ... can such app comp templ exist separately from assembly templates?
>   tobias: valid question. Q1: yes, Q2: yes, Q3: yes (need flexibility)
>   alex: tempted to say no
> 
>   MOTION: (gil) accept to open issue 35, 2nd Anish. No discussion. No objection. Passed w/o
> 
>   https://tools.oasis-open.org/issues/browse/CAMP-36   Use HTTP Patch and JSON Patch for updates to resources
> 
>   Anish: PUT not good for partial updates. PATCH is the way.
>   ... JSON PATCH format is an option
>   adrian: can we address this in #34?
>   anish: still relevant separately but we can link the 2 issues
>   adrian: the scheme to use PATCH should be shared across issues
> 
>  MOTION (adrian) open  Issue 36, anish 2nd. No discuss. No object. Passed w/o
> 
> 
> Issue Discussions:
> 
> 
>  https://tools.oasis-open.org/issues/browse/CAMP-12   Clarify scope of Application Components
> 
>    gil: proposal changes def of App Component in glossary appendix
>    anish: glossary normative by default
>    anish: no need for "keywords" to be normative
>    gil: diff between app comp and platform comp are more about management (user role)
>    anish: i'll create the links between issues 34 and 36
>    anish: current proposal is OK for now, another issue can take care of platform comp vs appl comp
>    chair: incremental improvement is OK
> 
>   MOTION: (gil) resolve issue 12 with proposal in JIRA, 2nd adrian. No discuss. No objection. Passes w/o
> 
> http://tools.oasis-open.org/issues/browse/CAMP-15  Use message-id and profile rather than uri and namespace
> 
>   adrian: about ID for error messages
>   anish: i have one suggestion for the proposal: s/A string containing a unique uuid or error number that references this particular message/A string containing unique identifier that identifies this particular message/
>   anish: another Q I have is: do we want say *globally* unique
>   anish: message ID not a URL. Just need be unique not necessarily globally.
>   Ashok Malhotra (Oracle): unique identifier is enough
>   adrian: no portability issue - only context is consumuer+provider
> 
> 
>  Adrian Otto (Rackspace): Use:
> 
>  | message-id | String | 0..1 | A string containing a unique identifier that identifies this particular message |
> 
>  Change to:
> 
> | message-id | String | 0..1 | A unique string that identifies this particular message |
> 
>  MOTION: (adrian) to resolve issue 15 with  proposal updated in preceding lines latest edit in the chat. 2nd (gil)
>   No discussion. No objection. Passes w/o
> 
> 
> 
> https://tools.oasis-open.org/issues/browse/CAMP-32 CAMP needs to say something about the serialization of null attribute values and empty arrays
> 
>  anish: camp attributes <--> JSON properties
>  gil: serialization of optional attributes
>  ... response to a GET should omit the absent attr
>  tobias: the def of such attributes (here description) should mention this optionally.
>  ... questioning the rationale behind this issue. Would motion to close the issue w no action.
>  adrian: 2 schools of thought: strongly typed approach (XML based), and JSON style less typed. Important to align w the style. a JSON API should not be so strict on attr presence. Conform to the style.
>  gil: interpretation problem. If attr has no value, be explicit about it.
>  Tobias Kunze: They key to this issue is that the platform implementation has no knowledge of the resource structure. As a result, it can't simply drop properties.
>  anish: @tobias do you mean client instead of platform impl in your comment above?
>  Tobias Kunze: I mean platform but applies for client as well
>  tobias: an impl cannot just drop an attribute.
>   ... 3rd party providers of Platform components might ignore such attributes
> 
>   chair: issue #32 needs more thoughts
> 
>   Adrian:  table discussion on 32. No objection
> 
> 
> http://tools.oasis-open.org/issues/browse/CAMP-30   Parameter Scheme
> 
>  adrian: create a template with a concept of variable in it (parameterized)
>   ... such values are dynamically passed at creation time
>   ... spares a PATCH
>   anish: more than just PATCH. Like this direction. Could also have another way to indicate (create a list of such parameterized attr)
>   anish: http://tools.ietf.org/html/rfc6570
>   gil: use case: creating multiple assemblies from a single template. Need to distinguish at creation time (can't just create clones then PATCH later)
>    ... may need a default value if not provided.
>  martin: proposal needs more in case $value not provided
>  jacques: need to look at mutability indication in the more general case?
> 
>  adrian: will elaborate on the issue , make link with #34, think about what happens when no value is provided and will look at RFC6570
> 
> AOB
> 
>  chair: next meeting on Dec 19, Meeting on 26 dec cancelled, need to decide next week whether to have a call on 2nd Jan 2013.
> 
>  Straggler roll: add jeff and rich 
> 
> Meeting Adjourned.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: camp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: camp-help@lists.oasis-open.org
> 



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