Define behaviour for two create events for the same tracked resource

    • Type: Improvement
    • Resolution: No Action
    • Priority: Major
    • Component/s: TRS
    • None
    • Hide

      The spec should define if it is valid, and if so, define the recommended behaviour of a link index provider that consumes those events.

      This is already covered in the spec with this clause:

      The TRS Provider SHOULD NOT report unnecessary Change Events although it might happen, for example, if changes occur while the Base is being computed. A TRS Consumer SHOULD ignore a creation event for a Tracked Resource that is already a member of the Tracked Resource Set, and SHOULD ignore a deletion or modification event for a Tracked Resource that is not a member of the Tracked Resource Set.

      Show
      The spec should define if it is valid, and if so, define the recommended behaviour of a link index provider that consumes those events. This is already covered in the spec with this clause: The TRS Provider SHOULD NOT report unnecessary Change Events although it might happen, for example, if changes occur while the Base is being computed. A TRS Consumer SHOULD ignore a creation event for a Tracked Resource that is already a member of the Tracked Resource Set, and SHOULD ignore a deletion or modification event for a Tracked Resource that is not a member of the Tracked Resource Set.

      The current TRS spec does not define whether it is valid for a TRS data provider to have two or more TRS creation events for the same tracked resource without an intervening deletion event, and if so, what the recommended behaviour is for a link index provider.

            Assignee:
            James Amsden (Inactive)
            Reporter:
            davidhoney
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: