Closed apannetrat closed 2 years ago
I left the crontabExample
field, but I believe that it's wrong here. In fact, in most cases, it contradicts the spec.
For example, the first metric, AIS-06-M1
, has a measurement frequency of 30 days. The crontab example sets the frequency to 31 days in January, 28 days in February, etc. which is not consistent with the metric, and could lead to implementation errors.
The crontabExample
also constraints the start of the measurement to a specific day of the month, which could lead readers to believe that the spec mandates a specific day of the month for measurements.
Previously we had measurements (which we used to call measures) as a subtype of a metric. One or more measurements come together as part of a mathematical or logical operation to produce a metric. This allows us to report on the measurements separately, potentially even spanning across metrics. There are 3 parts; a) the schema for measurements and metrics and b) publishing measurements from one or more providers and c) reporting on metrics based on the measures published.
Given the context, I would propose the following changes in the pull request: 1) I would prefer to rename "parameters" to "measurements" in the metricsModel.yaml. We should rename this file to metricsSchema.,yaml. We should also change "measurementFrequency" to "frequency" to be consistent with the naming convention 2) These measurements should correlate to the measurement reporting yaml(refer measures.yaml). This file needs to be renamed to measurementResults.yaml. All properties in measurementResults.yaml should be renamed to be consistent with the changes proposed in the metricsSchema.yaml
3/25 team discussion ok this PR.
raj has additional cleanup that will be a new PR & can drop unit & type