How should previousBaseline behave when an intermediate baseline is deleted?

    • Hide

      Modifying links leads to complications if the data is restored from an archive, so we will not require any such change. Instead, add a non-normative note:

      Since providers may support deletion of baselines, clients must not assume that references to baselines can be resolved; like any other resource, clients must be prepared to handle 404 errors. Since baselines are normally linked into a provenance chain using the oslc_config:previousBaseline property, servers may elect to leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline. Servers SHOULD add the property oslc:archived=TRUE on a reduced form of a partially deleted baseline.

      Show
      Modifying links leads to complications if the data is restored from an archive, so we will not require any such change. Instead, add a non-normative note: Since providers may support deletion of baselines, clients must not assume that references to baselines can be resolved; like any other resource, clients must be prepared to handle 404 errors. Since baselines are normally linked into a provenance chain using the oslc_config:previousBaseline property, servers may elect to leave a stub resource (one with a minimal set of properties) behind instead of truly deleting a baseline. Servers SHOULD add the property oslc:archived=TRUE on a reduced form of a partially deleted baseline.

      When a baseline is deleted, should existing baselines derived from the deleted one have their oslc_config:previousBaseline property updated to point to the previousBaseline of the one being deleted, to maintain the provenance chain? Or would this break things like digital signatures?

            Assignee:
            Nick Crossley (Inactive)
            Reporter:
            Nick Crossley (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: