[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 8th January 2014
Meeting Minutes 8th January 2014
Attendees:
US Department of Defense (DoD) Michael Behrens Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
NetApp Alex McDonald Voting Member
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Into:
SCRIBE: Gil
TOPIC: Roll Call
Attendees listed above, 10 of 12 (83%), quorate
TOPIC: Agenda
Martin> Agenda sent to mailing list
there has been some discussion of some of the issues on the mailing list.
Approved as posted
MartinC: Minutes:
TOPIC: Minutes
18th December 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201312/msg00074.html
MOTION: move to approve the minutes of 12/18/2013 - Ashok, s: Alex McDonald
Motion Passes by UC
TOPIC: Administrivia
Martin: We have 8 open issues, 1 P1, 3 P2, 4 P3
.. we're behind schedule
.. need to close comments down, resolve issues, and get to PR by end of Jan, early Feb
.. I'm going to be a bit harder on you guys
TOPIC: Editing Team Update
Jacques> Have been making progress
.. have raised some new normative challenges to the spec
.. these need to be dealt with before I can finish
.. change in attribute and resource names has to be dealt with
Martin> If TA development effects the main spec, we need to find this out ASAP
TOPIC: Issues Discussion
Martin> No new issues
CAMP-150 https://tools.oasis-open.org/issues/browse/CAMP-150
Anish is the scribe for issue 150
Gil explains proposal v5
.. now two ways for doing it by-value
Alex: this addresses my concerns
... we are asking ppl to support multiple ways for getting their applications into the platform
... but this is the core of the spec
... and requiring multiple ways to get in their applications is fine
... so support it
Jacques: if we are concerned about implementors not implementing all the ways, we can scale it down by defining different levels of conformance
Gil: willing to accept Alex's assertion for theses things. Not inclined to have multiple conformance level
Motion: m:gil s:AlexH resolve issue 150 with proposal v5 in JIRA
no objections, motion passes w/o.
SCRIBE: Gil
TOPIC: CAMP-155 https://tools.oasis-open.org/issues/browse/CAMP-155
Martin> There is a proposal
Gil> That proposal is out of date w/regards to the current state of discussion on the issue
Tom> How we resolve this effects CAMP-44
Gil> Isn't that the wrong way around?
Anish> Resolving this would help us resolve CAMP-44
Alex Heneveld (scribe): @Gil - why do we need to formally communicate that you'll never see the parent's optional "foo"
Gil> discusses the need to flatten the attribute_definitions array
Anish: i'm not sure we need to support such a feature
Ashok> then the sub-type can't stand-in for it's parent
Gil> it can if the attribute is optional in the parent
Anish: what's the motivation for this
Alex> we don't need to support this, most programming languages don't
... what's the harm if the attribute just happens to never appear?
Tom> if it is optional in the parent it means "it may or may not appear", that isn't compatible with "it cannot appear"
(general discussion on the idea of flattening the attribute_definitions array of the type_definition resource)
TOPIC: CAMP-146 https://tools.oasis-open.org/issues/browse/CAMP-146
Martin> there is no proposal for this issue
AlexH> I will write a proposal for this at some point, but I don't want to hold up the release of the spec
Martin> A proposal for this could be considered a material change to the spec, which effects the OASIS process
AlexH> if it comes to that, I will withhold my proposal
Anish> I think what we have is good enough
TOPIC: CAMP-152 https://tools.oasis-open.org/issues/browse/CAMP-152
Jacques> describes progress on this issue
Jacque> suggest we focus on the latest 4 points
Martin> I would prefer if we process these as new issues, otherwise we will never be done with CAMP-152
Jacques> I will do that
Jacques (Fujitsu): New issue for Normative Tag Challenges: https://tools.oasis-open.org/issues/browse/CAMP-158
TOPIC: CAMP-44 https://tools.oasis-open.org/issues/browse/CAMP-44
Anish> I've posted a rev 5 this morning
.. it's linked off the Jira
(Anish presents latest version of proposal (5))
Anish> not a lot of changes
.. deleted example that caused more problems than it clarified
.. fairly simple proposal
Ashok> don't know what it means to "semantically constrain"
Tom> you could have an attribute, in a super-type, which says "this attribute is an http or ftp URL"
.. the sub-type can say "this attribute is an http URL"
.. the sub-type is adding a semantic constraint
.. in our spec this can only be expressed in English
Ashok> can we say that you simply can't change the semantics?
.. would that cover it?
Anish> ultimate goal is substitutability
..this is the most liberal was of making sure things are substitutable
.. other ways are more restrictive on the Provider/Modeler
Anish: A sub-type MAY further restrict the constraints of an attribute inherited from its super-type(s). A sub-type SHALL NOT loosen the constraints of an attribute inherited from its super-type(s).
Alex Heneveld: @Martin the semantics of loosening constraints is clearer to me than loosening semantics ;)
Jacques> the way "substitutable" is used is ambigious
Anish: tom's suggestion: As a consequence, a resource of a sub-type can always substitute for a resource of any of its super-types.
(general discussion of what it means to be substitutable and the order of the "substitute" relationship)
Anish: As a consequence, a resource of a sub-type can always be substituted for a resource of any of its super-types.
Alex McDonald> in the case of multiple of inheritance, how can any sub-type replace any of its super-types
Anish> an *instance* of a sub-type can be replaced for an *instance* of its super-type
Alex McD> A, B, C, D; B and C inherit from A; D inherits from both B and C
(general discussion around "ignore things you don't expect" principle)
Anish: All our types are extensible, so you can add any additional attributes
Anish: the whole point is that if there is a type called "web server component"
Anish: ... i should be able to subtype that and add an attribute and use it where "web server component" is used
Jacques> the sentence "As a consequence, a resource of a sub-type can always be substituted for a resource of any of its super-types." is counter-intutive
(general discussion)
MartinC: As a consequence, a resource of a super-type can always be substituted with a resource of any of its sub-types
Michael Behrens: +1
Alex Heneveld: A superman can do anything that a regular man can do.
agreed changes: A sub-type MAY further restrict the constraints of an attribute inherited from its super-type(s). A sub-type SHALL NOT loosen the constraints of an attribute inherited from its super-type(s). [XXX-TAG] As a consequence, a resource of a super-type can always be substituted with a resource of any of its sub-types .
MOTION: Move to accept the v5 proposal+ changes (above) as a resolution to CAMP-44; m:Tom, s:Gil
Anish: here is the URL to v6: https://www.oasis-open.org/committees/document.php?document_id=51891&wg_abbrev=camp
Motion passes by UC
Jacques> moves to extend the meeting by 5 minutes
AlexH> 2nds, no objections
Motion passes by UC
TOPIC: CAMP-158 https://tools.oasis-open.org/issues/browse/CAMP-158
Jacques> (discusses point 4 for CAMP-158)
415 Unsupported Media Type
AOB:
Stragglers: Derek
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]