[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]