Major Is there a need for internally unique identifiers for info blocks? Intended to allow corrections to a single info block.
We in Canada update them all. We have a pararmeter in the block that basically indicates "no change here", or, what the minor change is for the block the parmater is in (there are 6 types). So this parameter declares the nature of the change. This is only for non substantial changes as anything substantial is a full Update.
For consumers that use continuous signalling (web pages, cell broadcast, road side signs, crawlers, etc...) the new one will look like the old one so go ahead and process. From the audience point of view, the minor change would show up only for the display using the info block where the change happened.
For consumers that use instantaneous signalling (text, email, etc...) they can ignore the minor change except for the change type they are interested in, if any. The one we use a lot is "text" where text now appears in the <description> element where it wasn't there before (Note: by federal policy we have to delay free form text in one language until its available in both. Since we have some free form text we have this delay).
Since this approach conforms to the "Wipe and replace" nature of CAP there is no need to ID an info block in our opinion. Markers in the block are used to decide if the block is to be processed or not.
Norm provided some use cases for why info blocks could be linked, primarily for multilingual messages to allow a recipient to determine the matching English and French versions. Jacob discussed the use case of an external link that would not only point to the alert message (sender, identifier, sent) but also to the respective info block using the UID. The original issue and subsequent comments also discussed partial updates, whereby one info block would be updated versus another. The group agreed this would introduce a lot of complexity, be a concern for implementation, and that the element would have to be optional. Norm raised the concern that CAP needs to remain simple and easy to use and the community may not be ready for partial info block updates.
The motion to resolve issue 12 as “deferred to a future version” and close it in JIRA, was put forward. Rex moved and it was seconded by Steve Hakusa. All agreed with the motion and it passed.
Should update all info blocks even if only one updated; partial updates probably not a good idea?