[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 9th January 2013
Minutes 9th January 2013 Attendees: Behrens, Michael US Department of Defense (DoD) Voting Member Carlson, Mark Oracle Voting Member Chapman, Martin Oracle Chair Durand, Jacques Fujitsu Limited Voting Member Heneveld, Alex Cloudsoft Corporation Limited Voting Member Janssen, Gershon Individual Voting Member Johnston-Watt, Duncan Cloudsoft Corporation Limited Voting Member Karmarkar, Anish Oracle Voting Member Kunze, Tobias Red Hat Voting Member 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 Rutt, Tom Fujitsu Limited Voting Member Tupitza, Charles JumpSoft Member Yendluri, Prasad Software AG, Inc. Voting Member Agrawal, Roshan Rackspace Hosting, Inc. Observer Intro: Ashok assumes scribe duties. Roll: Attendees listed above 16/19 meeting is quorate Agenda: Skip Camp-18 as there has been no progress. Agenda approved as modified. Minutes: 2nd January 2012: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201301/msg00005.html Motion: m: Gil, s: Michael approve 2nd jan minutes. Passed w/o Action Items: ACTION-20130102-0: Done Martin: Waiting to hear back from Jane Martin: Asked organizers about hosting f2f F2F: Martin: f2f in 2 weeks Adrian: Enough RSVPs for a quorate meeting Adrian: There will be a call-in bridge Martin: Pl. think about open issues and prioritize them Anish: We will need proposals for the top-priority items Gil: Issues 1, 10 and 14 are connected we need to resolve these early ... let's try and resolve them at the f2f Duncan Johnston-Watt: +1 #10 Anish: Extensibility issues are all tied together ... need to resolve Duncan Johnston-Watt: +1 #1 Jacques: Pl. allocate at least half a day to testing. I have posted a draft. Pl. review. Adrian: Issues 1 and 14 are unassigned. Need to assign to make progress. Tom Rutt (Fujitsu): you can assign issue camp 17 to myself Anish: I can volunteer for issue 1. I have a proposal in Jira. Gil: I can take 10 and 14 Adrian: There are a number of things that need to be discovered. Anish: Pl. comment on the issue Discussion on what needs to be discovered Michael: Should we ask someone from CDMI or OCCI to present? Anish: don't we need a TC member who is familiar to volunteer to talk about it? Michael: I will send mail to Martin and copy someone from OCCI Michael Behrens: I'll contact the OCCI WG (will CC Martin) to check feasibility. Editing Team Update: Anish: WD2 has been put out https://www.oasis-open.org/apps/org/workgroup/camp/download.php/47749/camp-spec-v1.1-wd02.pdf ... includes some issue resolution ... we should publish a CSD to set a baseline Anish: We should publish often Anish: You can create a CSD without a public review Martin: The change bars are wrt version 1 and 1.1 ... issue resolutions will show up. Stylistic changes will not show up. Motion: m:Gil, s: Anish moves to publish WSD02 a CSD01 and publish in the TC repository only. No objections. Passed w/o Jacques talks about connection from the spec to the test assertions doc - discuss at the F2F New issues: http://tools.oasis-open.org/issues/browse/CAMP-38 resourceState attribute needs clarification Gil discusses the issue Motion: m:Gil, s:Anish moves to open CAMP-38. No objections. Passed w/o Issue Discussion: http://tools.oasis-open.org/issues/browse/CAMP-25 Refine link structure Gil presents his proposal Gil: I think we should add a name attribute to the link in addition to the href Gil: I thought earlier proposal was too complicated Michael: Also consider use of Rel in the Link ... there is an RFC Ashok: Do we need a link "type" Jacques: Asks about link functionality -- change name to be more descriptive Gil: I'm okay with calling it "linkedResourceName" Anish: RFC 5988? ... that's different Michael Behrens: Yes: http://tools.ietf.org/html/rfc5988 Anish: In our case the relationship is very clear ... the name tells you what you are going to traverse Anish: Link is extensible. You can add other attributes Gil: no Michael Behrens: Also, suggest see how OCCI solved this CAMP-25: www.gridforum.org/documents/GFD.184.pdf Tobias: It is good to put the relevant info is in the link itself Gil: All links are contextualized by where they occur Gil: The info is in the spec. Why do we need to have it in the link? anish: the link type is extensible Gil: All we need is what it is a link to anish: so you can add any other info that you want Tobias: The code that is issuing the request needs to know the info. ... better if info is in the link rather than in the spec anish: in HTML it is <link href="..." ref="..." .../> in CAMP it is assembly: [{'href': "..."}, {'href': "..."}] anish: so in CAMP all the href in the above example are pointers to assemblies anish: the name of the attribute tells you almost everything you want to know. ...But if you want to put more info, it is extensible and you can add more info Adrian: Is something broken or do you need an optimization anish: gil's proposal is to change the current spec to something like this -- assembly: [{'href': "...", name="foo"}, {'href': "...", name="bar"}] Gil: E.g. which servlet engine my app server is running on ... I do a GET in the assembly and this contains links to components anish: better example would be -- assembly: [{'href': "...", name="hello-world"}, {'href': "...", name="pet-store"}] ... I cannot tell which URI to to a GET on to find which represents my WAR file ... I have only hrefs. I little hint as to what the link refers to would be useful Adrian: Aren't you denormalizing the structure ... if you change the name don't you need to fix where the name is referred to Anish: The user does not directly edit the links ... the platform maintains them Gil: this is what my proposal currently has in it w/regards to the semantics of "name" Gil: This attribute echoes the value of the ?name? attribute of the resource referenced by this Link. ... The value of this attribute may be changed by the Platform. Users may not change the value of this attribute. Gil: Adrian, any specific wording suggestions? Anish: We would need to say platform must fix references when name is changed anish: gil, ok. forgot about that Adrian: Need more detail in proposal Jacques (Fujitsu): #25: replace "name" with "linkedresource" or "linkres" or the like Gil: Jacques - "linkedResName" ? Gil: I want to indicate that it is a reflection of the "name" attribute No conclusion on camp-25 Martin: No progress on the other issues AOB: Straggler Roll: Alex Heneveld MEETING ADJOURNED
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]