[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (CAMP-169) CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
[ https://tools.oasis-open.org/issues/browse/CAMP-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Chapman updated CAMP-169: --------------------------------- Resolution: From 11th June 2014: Motion: Gil: Moves to accept his proposal in JIRA as resolution for ISSUE-169. Alex seconds Resolved without objection Incorporate the resolution in WD 42 (https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53302/camp-spec-v1.1-wd42.doc). was:Incorporate the resolution in WD 42 (https://www.oasis-open.org/apps/org/workgroup/camp/download.php/53302/camp-spec-v1.1-wd42.doc). > CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013) > --------------------------------------------------------------------------------------- > > Key: CAMP-169 > URL: https://tools.oasis-open.org/issues/browse/CAMP-169 > Project: OASIS Cloud Application Management for Platforms (CAMP) TC > Issue Type: Bug > Components: Primer > Reporter: Martin Chapman > Assignee: Gilbert Pilz > > https://lists.oasis-open.org/archives/camp-comment/201402/msg00001.html > Hi Adrian, > Recently I got a chance to take a look at CAMP working draft 39 (dated February 3, 2014). > I was specifically looking to see how the issue filed here > https://tools.oasis-open.org/issues/browse/CAMP-153 > has been resolved. > Upon reading through the comments on the issue, I am not sure I agree to the > justification given to keep two different service specification formats. > If I understand the justification correctly, it is saying that > the 'in-line' format of service specification is useful for the use case when multiple artifacts *don't* > want to share services. In such situations, the required services can be specified > 'in-line' with each artifact, whereas, if multiple artifacts need to share a service (same instance of it) then such a > service specification should be defined in the services section. > I still think that one could achieve both these use cases by having a single > way of defining required services in a separate top-level services section. > Having two different formats will lead to model interpreter complexity > without providing significant gain. > If, however, the TC wants to keep two different formats then one suggestion that I would like to make > is to enforce the distinction through the specification. > Currently the 'in-line' format is still exactly same as the 'out-of-line' format, > the specification does not explicitly restrict/enforce when to use one over the other. > One way to enforce this would be to remove the 'id' field from the 'in-line' definition of a service. > That way, it won't even be possible to reference an in-line defined service from outside > the defining artifact's scope. (to be concrete: remove 'id' from being a child of 'fulfillment' node > on line 14 of page 31). > In case this is not an option then another suggestion would be to at least explicitly call out > in the specification the need for providing two different ways to specify services and to suggest when > one format should be used over the other. > Regards, > Devdatta -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]