OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[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


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

      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

  5th March2014:  https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201403/msg00010.html 

      Martin: any comments?
      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

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.


      Stragglers: none
      Martin: any other topics?

Meeting Adjourned

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]