[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes 12 March 2014
Meeting Minutes 12th March 2014 Attendees: US Department of Defense (DoD) Michael Behrens Member Software AG, Inc. Bhaskar Reddy Byreddy 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 Rackspace Hosting, Inc. Adrian Otto Chair Vnomic Derek Palma 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: Scribe: Gil Roll: Attendees listed above, Voting Members: 11 of 11 (100%) meeting is quorate. TOPIC: Agenda Martin: I've posted a new agenda due to the appearance of a new issue any comments? any objections to approving Agenda Approved as Posted Minutes: 5th March2014: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201403/msg00010.html Martin: any comments? (silence) Motion: Approve the minutes of 2014-03-05 m: Anish s: Ashok Motion Carries TOPIC: Administrivia Martin: not much to say ... TOPIC: Editing Team Update (silence) TOPIC: New Issues CAMP-167: https://tools.oasis-open.org/issues/browse/CAMP-167 Ashok: There has been an update to the JSON RFC ... it is a relatively small update, but we should at least consider updating our reference Anish: I sent an email to the list on how the changes affect CAMP ... this is a breaking change (mostly around BOM and character set restrictions) ... if there are other issues that would force us to do a new PR, we should make this change Tom: Haven't they split JSON out of the ECMAScript standard? Gil: isn't our dated reference okay? Gil:if we are going to change, perhaps we should consider referencing an international standard version AlexH: the bit where you don't have to use curly braces is a pretty radical change ... there doesn't seem to be any library support for that ... this could make it very difficult to conform to CAMP Tom Rutt (Fujitsu)2: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf The JSON Data Interchange Format Anish: this doesn't effect CAMP because each of our resources is a list of attributes - and therefore needs curly braces AlexH: this makes returning sensor values easier then ... in the case where the value is a simple integer ... it makes sense to open this issue anish: From Tim's blog: anish: "Anyhow, by my count, the Internet now has at least 5 different things that can be thought of as JSON specifications. Fortunately, everyone pretty well agrees on the right way to do JSON, so thats not a problem." AlexM: it's become clear that there is a competition between ECMA and IETF as to who owns JSON Tom: we don't want to add features to CAMP that aren't implemented Martin: do we open this issue? Anish: I think we ought to open it (sound of issue inflating in scope) Motion: open CAMP-167 m: Anish, s: Ashok Martin: P1, P2, or P3? ... or do we really care? Anish: I think it is a P3 Gil: anything to do with normative references is P1 in my book ... if people feel strongly about it, P3 is ok Motion: open CAMP-167 as a P3 issue; m: Anish, s: Ashok Motion Carries anish: @tom, i just briefly looked at the ECMA 404, and it is very short. And doesn't have any discussion around interop, BOF. I think the IETF spec is better TOPIC: CAMP-168 https://tools.oasis-open.org/issues/browse/CAMP-168 Adrian: this concerns the content of the Plan file (camp.yaml) ... we have a thing called a Requirement Specification ... it contains a node/attribute called "requirement_type" ... the trouble with calling it a "requirement_type" is that, in order to wire artifacts to services, you need to programatically determine which services satisfy the Requirement Specification ... calling this string a "requirement_type" confuses both implementers as well as end-users of CAMP ... we are seeking an approach to clarify how requirements are expressed ... one approach is to rename it, the other is to restructure it into key/value pairs as it is, this is confusing ... almost everyone that has read it has remarked on their inability to understand it Martin: is this just a naming change or are you looking to change the descriptive text? Adrian: my goal is to make it more clear; whatever it takes AlexH: I know what I meant when I wrote that but, at the very least, some more examples would make it clearer ... it may or may not result in a material change ... this deserves consideration especially if it is confusing people Motion: Open CAMP-168 as a P2 issue; m: Adrian, s: AlexH Motion Carries TOPIC: Deferred Issues Martin: I did some investigation into some of our deferred issues and wrote a brief summary of our findings ... "deferred" state is only valid once you open the issue ... in our model you can move from "new" to "deferred" but this is not supported in JIRA yet ... some of the corner-case transitions will be addressed in the next version of Jira ...Meanwhile a number of our deferred issues have been targeted to the mythical primer ...we should move these to deferred ... I would like to do a bit of housekeeping to re-categorize these issues probably need a motion Motion: change state of CAMP-26, CAMP-77, CAMP-154 to "deferred" and set component to "new work product" (or some such); m: Martin, s: AlexH Motion Carries TOPIC: Issue Discussion Martin: haven't seen any proposals TOPIC: CAMP-163 https://tools.oasis-open.org/issues/browse/CAMP-163 Martin: If we resolve this issue as suggested, it will probably result in a non-backwards compatible change ... which isn't a reason not to consider it, but we should keep that in mind Adrian: I don't have any objections to doing another review cycle ... especially as we have no implementations of CAMP out there Gil: (blathers about two paths to resolve CAMP-163) AlexH: my experience is that, if we follow his primary approach, for any large application you will end up with a big, messy list of Service Specifications under "services" ... I would be opposed to flattening things completely ... changing the schema of a Service Specification based on where it appears in the Plan file makes things *more* complicated, not less ... I'm not convinced we have to change this Adrian: Devdata is concerned about the complexity of the parser for the Plan file ... having different ways of specifying the same thing makes the parse more complicated .... but complexity is implementation isn't our primary concern ... we should primarily be concerned with making things simpler for consumers (i.e. make it easy to write and understand Plan files) Alex Heneveld: +1 we should optimize for consumers/users, not the implementers Martin: I agree that it is about the users, not the implementers ... one of the dangers of dealing with IDs is simply typos that result in no matching or, worse, matching the wrong service ... in inline, is "id" optional for Service Specifications? Gil: yes Martin: then I would argue that the status quo is fine ... would anybody object if we did a "close with no action" Tom: there are a million things we could tweak, but I'm not convinced it is broken Martin: I note that this is the second time we have considered this ... it is okay to have our decisions challenged, but the indications are that the TC has made up his mind on this Adrian: some of this could be addressed in the (mythical) primer Jacques (Fujitsu): in favor of status quo as well. There are very large enterprise apps out there. Flat no good. Gil: I don't hear anyone speaking in favor of changing anything ... unless someone new joins the TC? Motion: close CAMP-163 with no action and reply to commenter stating our rationale for this decision; m: AlexH, s:Tom Martin: should open a new issue against "primer" to explain this aspect of the Plan file Motion Carries TOPIC: CAMP-164 https://tools.oasis-open.org/issues/browse/CAMP-164 editorial fixes Motion: resolve CAMP-164 with the changes in the description; m: Gil, s: Jacques Motion Carries TOPIC: CAMP-165 https://tools.oasis-open.org/issues/browse/CAMP-165 Martin: last call we seemed to agree that RDF would be nice, but we don't intend to do that in this version of the spec ... I had an action item to respond to issue raiser Gil: did you carry out your action item Martin: I wanted to resolve the issue first Motion: defer CAMP-165; m: Gil, s: Ashok Motion Carries TOPIC: CAMP-166 https://tools.oasis-open.org/issues/browse/CAMP-166 Alex Heneveld: folks - have to drop off shortly for a 6pm call Alex Heneveld: no strong feelings on this issue :) misc. discussion of the nature of the issue Martin: we don't allow people to define extensions that change the value space of an attribute Adrian: correct, we don't allow extensions to contradict the spec Gil: how does Solum do this? Adrian: Solum doesn't do this (pull child resources into their containing resource) at the top level ... Solum does this in places where you have Link arrays ... you get arrays of entities instead of arrays of link to entities ... when you ask for a list you want a list of elements, not an array of links to elements Gil: Solum preserves the name of the array attribute? Adrian: yes Jacques: I've seen this same concern in the CIMI spec ...when you query a complex object, you can ask the provider to "expand" the references which will consolidate the ... resource by including the referenced resource as child objects of the referring resource .... so it seems to make sense to make the attribute names more generic Tom: this is a good thing to do but do we want to do it now, or later Gil: we had an issue about precisely this and decided to defer it Tom: it seems like a popular idea Gil: CAMP-166 isn't about pulling up child resources ... it is about changing the name of attributes names "*_uri" by "s/_uri//" Jacques: this makes making the change for pulling up children easier in the future Adrian: you can still add an extension where you, for example, add an attribute name "services" which contains the resource that is referenced by "services_uri" Gil: the "_uri" isn't the problem in making the kind of extension proposed in the issue ... the real problem is that you can't contradict what CAMP says ... if CAMP says "banana_uri" is a URI, an extension can't make it be a JSON object Tom: we have to think about future versions ... we could defer this until a later version of CAMP Jacques: it all depends on how we look at this ... I don't look at this an attempt to sneak in an extension ... we could have, as a general rule, that references may or may not be expanded ... we could single out all references and apply a general rule to them ... we aren't trying to make it easy to violate CAMP ... this is a useful feature to single out references Adrian: we shouldn't be concerned about future versions ... we've designed in concurrent version support ... if we want to change attribute names in future versions, we can do that Gil: An attribute that can be either a URI or a JSON object is a bad idea ... too hard to parse Adrian Otto (Rackspace): I concur with Gil's remarks that using a single attribute with potentially different value spaces makes client-server communication more complicated. ... It's a better practice for a single attribute name to have a single type value. If you want an alternate, use another attribute name. Jacques: the change suggested by this issue now seems to be a bit premature to me MartinC: agreed at the moment the content must be a uri - if we are going to generalise the content and hence the name that is a new feature imho issue stays open for more thought. TOPIC: AOB Stragglers: none Martin: any other topics? (silence) Meeting Adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]