[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 18th December 2013
Meeting Minutes 18 December 2013
Attendees
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 Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Red Hat Krishna Raman Voting Member
Fujitsu Limited Tom Rutt Voting Member
Software AG, Inc. Prasad Yendluri Voting Member
Intro:
Alex Heneveld assumes scribe duties.
Roll: Attendees listed above. Quorate -- 11 of 12 = 91%
Agenda: approved as posted
Minutes:
11th December 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201312/msg00042.html
motion to approve minutes, gil s:anish. carried w no objections.
Admin:
reminder from chair: no meetings for next two weeks due to holidays
Editing Team Update:
wd34: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51700/camp-spec-v1.1-wd34.doc
TA should be ready by next meeting.
New Issues:
None
Issue Discussion:
https://tools.oasis-open.org/issues/browse/CAMP-150 mechanism for creating an Assembly (or Plan) by value (i.e. POSTing the contents of a PDP or Plan file) is difficult to use
Gil presents his proposal
Alex Heneveld: i'm not convinced by this issue: http://stackoverflow.com/questions/6396101/pure-javascript-send-post-data-without-a-form
Anish: see http://stackoverflow.com/questions/10765243/how-can-i-rewrite-this-curl-multipart-form-data-request-without-using-f
Alex Heneveld: motion to accept the v4 proposal from gil, s: tom (?)
motion to accept the v4 proposal from gil, s: tom (?)
Alex McDonald (NetApp): is it "curl --data-binary <data>" that is the issue?
Alex Heneveld: Alex H would like to see this proposal allow clients to post a plan using data with content type application/x-yaml, with no need for forms.
Adrian moves to table the motion, Gil attempts to withdraw the motion, and then Gil seconds the tabling.
https://tools.oasis-open.org/issues/browse/CAMP-44 Clarify resource type issues and API
Anish presents his proposal.
Alex Heneveld: @AlexM - this isn't a parsing issue, this is a design issue.
MartinC: indeed this is a constraint that can only be written in english
Alex Heneveld: several lines up there is the statement that "sub-type SHALL NOT loosed the constraints and semantics of super-type" <- this is also not testable
Alex Heneveld: two minor mistakes
Alex Heneveld: in para 1 we refer to "its super-types" and to "its super-type" <- we should be consistent
Gil Pilz (Oracle): Alex - the editors can fix those
MartinC: "other documented constraints, they may not be parseable,..."
Alex Heneveld: in para 2 where we say "and type C inherits from A and B, then this is considered an error"
... change it to "then it is an error to define a type C which inherits from both A and B"
Alex Heneveld: (para 2 is like saying "if 1+1=3, then this is considered an error" :) )
Alex Heneveld: apart from that i like it. good job anish.
Alex Heneveld: +1 Anish - we need to take a stance on normative assertions which are hard to test formally
MartinC: maybe add a note: Note: constraints may be written in English and might not be automatically parseable.
Alex Heneveld: Anish's example is fine -- it is a red herring whether the constraints/semantics are formally testable or not. sometimes they will be and sometimes they won't be.
MartinC: there be dragons either way!
Alex Heneveld: +1 Tom's weaker idea, "Implementers should take particular care when implementing from two resources with attributes of the same name" instead of a normative statement
Gil Pilz (Oracle): The reason we got into this fuzzy territory is that we didn't want to *prohibit* the use of the diamond pattern in cases where it was possible to simultaneously satisfy the semantics of colliding attributes even though authors of both of the parent resources didn't know that such a thing was possible.
Alex Heneveld: (we already have the normative statement "sub-type SHALL NOT loosed the constraints and semantics of super-type" thus this additional normative statement in the case of multiple inheritance is redundant.)
MartinC: a syntax checker can raise the potential clash - the user can then go look to see if there is a semantic mismatch and make the right (or wrong) decision
MartinC: we cannot have strong type checking without reference to another definition language
Tom Rutt (Fujitsu): If there is an attribute name collision resulting from multiple super types, the syntax of that attribute SHALL be identical. At the time a resource type is specified using multiple inheritance, the designer needs to ensure that the semantics of attributes with the same name are compatible.
Alex Heneveld: +1 Gil = -1 Tom's stronger approach. It will make it harder to adopt support standardised types.
Jacques (Fujitsu): it is a model design issue - you don't test for modeling mistakes. Anish is stating a modeling rule here.
Jacques (Fujitsu): ... so I would not worry about testing.
Tom Rutt (Fujitsu): If there is an attribute name collision resulting from multiple supertypes, and the syntax of the attributes are identical, then the subtype treats that attribute as a single attribute in the subtype. Note: at the time a resource type is specified using multiple inheritance, the designer needs to ensure that the semantics of attributes with the same name are compatible.
Alex McDonald (NetApp): OK, I'm going to object here because this is going to cause run-time problems; since there's no design time checking.
Gil Pilz (Oracle): "neither shall thou count to 3, unless then proceeding to 4"
Alex McDonald (NetApp): I'm not going to stand in the way of issues raised by CAMP-44, and the attempted resolution here, but I'm not a happy bunny... So that's for me to suggest then!
Alex McDonald (NetApp): I'll add to CAMP-44
Alex Heneveld: @AlexM - we have the same problem without inheritance -- it's impossible to formally test that a resource always conforms to the semantics of its type definition. or that implementations are correct or well behaved. that doesn't stop people using types. that's the problem with semantics. but without them everything is meaningless!
Anish to work on v4
AOB:
No stragglers.
Happy Holidays!
Meeting Adjourned.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]