Discussion: Is the prominent handling of stateTag necessary anymore
The stateTag attribute was attribute that was present in many resource types. But in the current version of the specifications it is only functional present in the following resource types:
- <container> : Here it acts as a kind of counter for adding an incremented tag in new <contentInstances>
- <contentInstance> : Added by the CSE to represent some kind of order of the received values
- <flexContainer> : Here it acts as a counter for the number of updates a specialisation resource received
The procedures for these resource types separately describe what actions should be applied to the stateTag attributes. But there is also the generic procedures that still describe what actions to apply to this attribute. This leads to some ambiguities, such as when this attribute shall be incremented, for example when a <contentInstance> is added or deleted:
- Addition: Is a <container>'s stateTag incremented since the addition of a child <contentInstance> also modifies its <container>.
- Deletion: The deletion, either explicitly (via a DELETE request) or implicitly (via expiration or <container> overflow) leads to a modification of the container. Is in this case the <container>'s stateTag incremented? The procedures don't mention this, but the general rules do, but does it make sense?
Since the stateTag is now only used by three resource types, wouldn't it make sense to remove all of the ambiguous generic rules, e.g. TS-0004 7.3.3.7 ?
There are also a couple of clean-ups in TS-0004 necessary:
- The procedure defined for stateTag in <flexContainer> in TS-0001 are not mentioned in the procedures in TS-0004
- stateTag is mentioned in diagrams and examples, e.g. E.2.
- Update the "occurs in" column in the short name Table 8.2.31 .