Uploaded image for project: 'OASIS Cloud Application Management for Platforms (CAMP) TC'
  1. OASIS Cloud Application Management for Platforms (CAMP) TC
  2. CAMP-201

Consumer mutability of attributes and attribute types

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: Spec
    • Labels:
      None
    • Proposal:
      Hide

      Few ways we could deal w/ this:
      1) No change. Instance specific mutability or authorization issues are deal with via a round trip and an HTTP error code.
      2) Remove consumer mutability of the attribute from the spec
      3) Leave the consumer mutability of attributes in the spec, but not define the values in the spec. Let platform impl decide. They may decide to leave it in the type off the platform or make it instance specific. HTTP caches work using the URL, an instance that points to the type will work just fine with HTTP caches.


      Based on the 2015-10-28 call, option (2) was acceptable. Proposal for option (2) is at https://www.oasis-open.org/committees/document.php?document_id=56855&wg_abbrev=camp


      Based on 2015-11-04 telcon, updated v2 proposal: https://www.oasis-open.org/committees/document.php?document_id=56859&wg_abbrev=camp


      Based on 2015-12-02 telcon, updated v3 proposal: https://www.oasis-open.org/committees/document.php?document_id=57080&wg_abbrev=camp
      On 2015-12-02 telcon the TC agreed to have the following:
      1) both mutability and consumer-mutability as metadata
      2) this is associated at the instance level not type
      3) The spec will not specify whether the values are true or false
      4) It is the platform that decides the values and must provide that information to the consumer


      v4 of the proposal is located at: https://www.oasis-open.org/committees/document.php?document_id=57565&wg_abbrev=camp
      This proposal is based on agreements at https://www.oasis-open.org/apps/org/workgroup/camp/download.php/57517/mutability_outline-3.txt and the 2016-02-18 telcon.

      Show
      Few ways we could deal w/ this: 1) No change. Instance specific mutability or authorization issues are deal with via a round trip and an HTTP error code. 2) Remove consumer mutability of the attribute from the spec 3) Leave the consumer mutability of attributes in the spec, but not define the values in the spec. Let platform impl decide. They may decide to leave it in the type off the platform or make it instance specific. HTTP caches work using the URL, an instance that points to the type will work just fine with HTTP caches. Based on the 2015-10-28 call, option (2) was acceptable. Proposal for option (2) is at https://www.oasis-open.org/committees/document.php?document_id=56855&wg_abbrev=camp Based on 2015-11-04 telcon, updated v2 proposal: https://www.oasis-open.org/committees/document.php?document_id=56859&wg_abbrev=camp Based on 2015-12-02 telcon, updated v3 proposal: https://www.oasis-open.org/committees/document.php?document_id=57080&wg_abbrev=camp On 2015-12-02 telcon the TC agreed to have the following: 1) both mutability and consumer-mutability as metadata 2) this is associated at the instance level not type 3) The spec will not specify whether the values are true or false 4) It is the platform that decides the values and must provide that information to the consumer v4 of the proposal is located at: https://www.oasis-open.org/committees/document.php?document_id=57565&wg_abbrev=camp This proposal is based on agreements at https://www.oasis-open.org/apps/org/workgroup/camp/download.php/57517/mutability_outline-3.txt and the 2016-02-18 telcon.
    • Resolution:
      Show
      Resolved in WD 07: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/57679/camp-spec-v1.2-wd07.doc

      Description

      The spec currently defines consumer mutability of an attribute in the attribute type definition. Questions have been raised about whether that is appropriate. Few scenarios that complicate this:
      1) Collection type 'items' attribute may be mutable or not depending on the kind of collection.
      2) the consumer mutability of an attribute may depend on an instance not the type. Moving this to the type necessitates unnecessary invention of additional types
      3) the mutability of an attribute may depend on other factors such as authorization/credentials of the consumer or it may change with time (because changing the attribute value may make something else inconsistent).

      Issues 180, 196, and 199 depend on resolution of this issue.

        Attachments

          Activity

            People

            • Assignee:
              akarmark Anish Karmarkar
              Reporter:
              akarmark Anish Karmarkar
            • Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: