[OASIS Issue Tracker] Updated: (CAMP-169) CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/CAMP-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Chapman  updated CAMP-169:
---------------------------------

    Component/s: Possibe Work Products
                     (was: SPEC PR2)

> CLONE -Feedback/Questions on CAMP Version 1.1 Working Draft 32 (Dated: 5 December 2013)
> ---------------------------------------------------------------------------------------
>
>                 Key: CAMP-169
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-169
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Possibe Work Products
>            Reporter: Martin Chapman 
>
> 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 is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira