add clarification on data updates

[tomkralidis]

Add to section for data publishers:

If a data publisher issues an update on a data granule, the associated WNM should:

• keep the same properties.data_id
• update the link object to use rel=update to refer to the updated granule (not rel=canonical)
• update properties.pubtime

[6a6d74]

Also add section for Implementation and operation of a Global Service / Global Cache.

Expected behaviour is described below:

The first aim of updates is to make sure that the (potentially) faulty data in the initial message will not be used by downstream processing by the users.
It means that, the initial download link in the cache should either be made unavailable or the file is updated 'in place' and reuse the same link.

Using an example:

        "links": [
            {
               "rel": "canonical",
               "type": "application/x-bufr",
               "href": "[http://wis2bra.inmet.gov.br/data/2024-05-22/wis/br-inmet/data/core/weather/surface-based-observations/synop/WIGOS_0-76-0-1709500000000161_20240522T030000.bufr4](http://wis2bra.inmet.gov.br/data/2024-05-22/wis/br-inmet/data/core/weather/surface-based-observations/synop/WIGOS_0-76-0-1709500000000161_20240522T030000.bufr4)",
               "length": 240
            },
            {
               "rel": "update",
               "type": "application/x-bufr",
               "href": "[http://wis2bra.inmet.gov.br/data/2024-05-22/wis/br-inmet/data/core/weather/surface-based-observations/synop/WIGOS_0-76-0-1709500000000161_20240522T030000.bufr4](http://wis2bra.inmet.gov.br/data/2024-05-22/wis/br-inmet/data/core/weather/surface-based-observations/synop/WIGOS_0-76-0-1709500000000161_20240522T030000.bufr4)",
               "length": 240
            },

when you get this message from Brazil the cache must:

• redownload the data using the link
• 'replace' the original file so
  a. delete the old one and create a new file with a new link
  b. replace the existing link and overwrite the content
• change all the links in the WNM that sends back to the origin
• publish a new message with a new id and the same data_id.

So, using this example above, the canonical and the update href must be changed to send to your cache.

If there is only a link with rel=update the GC should add a copy of the link to the WNM, albeit with rel=canonical

Note that client applications should always be looking for a link with rel=update first, then rel=canonical.

[antje-s]

I have the following questions about the behaviour described:

1. Should the cache really change the filename of updates to match the canonical when the centre sends a new, different filename? In my view, the responsibility here should lie with the centre that sends the updates. The same filename should already be used here.

2. In my opinion, no canonical is necessary for rel=update and rel=delete. Since rel=update and rel=delete are searched for first and rel=canonical is only used if there are no hits.

[tomkralidis]

2. In my opinion, no canonical is necessary for rel=update and rel=delete. Since rel=update and rel=delete are searched for first and rel=canonical is only used if there are no hits.

Note that TT-WISMD is addressing this as per wmo-im/wis2-notification-message#82 (comment)