Closed tomkralidis closed 1 year ago
FYI I have added a PDF output in the PR to review "in context".
Hi Tom,
not sure how to send comments the best way... Would it be ok directly as content here?
1) Abstract "WIS2 Notification Message documents shall be encoded in GeoJSON (RFC7946 [4]) as defined in this specification and shall be made available as MQP payloads or via API provisioning as defined by OGC API - Features." --> If MQP messages are the default and the API is optionally e.g. for specific requests (that's how I would have understood it so far)... "WIS2 Notification Messages shall be encoded in GeoJSON (RFC7946 [4]) as defined in this specification and shall be made available as MQP payloads. Additional they can be provisioned via an API as defined by OGC API - Features."
2) 6.2.1. Publish, Subscribe, Download "Notifications provide information to ensure data integrity, authoritative data retrieval source(s), and spatiotemporal extents of a data granule." --> "authoritative data retrieval source(s)" An organizational regulation for new WIS Node Message Brokers before adding to Global Message Broker Sources is important. Any source integrated there is likely to be regarded as relatively trustworthy by the recipients. For this reason I would prefer to remove the sentence part here
3) 7.1.3. Identifier suggestion for addition... "The message id is set to a new value by the Global Caches when they publish their modified message for accessing the original core data via the cache. The data_id is kept so that it remains traceable that it is the same product."
4) 7.1.4. Version "A WNM’s version property SHALL be fixed to v04." --> "The WNM’s version property SHALL be fixed to v04 for this message format version"
5) 7.1.7.2. data_id "A WNM’s properties.data_id property SHALL contain a valid WIS2 topic, without the channel and version." --> Is this already set? I thought it just had to be unique, data_id could include the topic value (without channel and version)
to be added (as mentioned in the text above): Requirement 7 C - A WNM’s properties.data_id property SHALL be unique
...
...(part 2) Further suggestions...
7.1.2 rename title "Validation" to "compliant with GeoJSON"
properties Requirementsnames to include properties: -- 7.1.7.1. pubtime: Requirement 6 /req/core/pubtime --> /req/core/properties/pubtime -- 7.1.7.2. data_id: Requirement 7 /req/core/data_id --> /req/core/properties/data_id -- 7.1.7.3. Temporal description: Requirement 8 /req/core/temporal --> /req/core/properties/temporal ...
7.1.7.4. Integrity --> Should be changed to "SHALL" (and required under https://github.com/wmo-im/wis2-notification-message/blob/main/WIS2_Message_Format_Schema.yaml ) : otherwise no verification of the download is possible if it is not included
7.1.7.5. Content Perhaps adding something like: "The inline content filed is useful for warnings to avoid the extra step of downloading. But also for warnings the maximum size must not be exceeded" Splitting of "A WNM SHOULD provide a content property, consisting of an encoding property (fixed to either utf-8 or base64), a value property (of less than 2048 bytes) of the data, as well as a size property with the length of the data." --> to perhaps A - "A WNM SHOULD provide a content property, consisting of an encoding property, a value property, and a size property" B - "The content encoding property is fixed to either utf-8 or base64" C - "The size of the content value SHALL be of less than 2048 bytes"
7.1.8. Links F - A WNM SHALL provide links using using HTTP, HTTPS, FTP or SFTP. (typo "using using")
In general, I find the document very good and clearly structured
7.1.7.4 See #19
Now, when I see the discussion about the content
property, in v03
the embedded message can be compressed with gzip
, which is very useful for IWXXM and other XML-based formats (CAP) to make them embeddable. Was this feature lost in v04
? I cannot find an explicit notion of compression.
@antje-s @josusky @kaiwirt thanks for the valuable feedback.
gzip
is now added back to the properties.content.encoding
enum.An updated PDF "in context" based on the above can be found here.
@antje-s having said this, given the goal of the PR is to move to the OGC ModSpec format, let me know if we can follow up on the outstanding issues in subsequent issues/discussions?
OK
Updates specification to the OGC ModSpec form (structure/workflow is identical to WCMP2).
PDF example output: wis2-notification-message.pdf
cc @golfvert @efucile