The key identifying an element in the object SHOULD be a unique string within the details section. It MAY have two parts: “{componentName}:{measurementName}”, in which case the meaning of the parts SHOULD be as follows:
The first sentence of this paragraph should be changed to read (emphasis only to highlight the changes):
The key identifying an element in the object SHOULDMUST be a unique string within the detailschecks section.
The JSON structure that this specification describes will fail in many linters and languages if the keys are not unique. The linters I tried all show a duplicate key error. When marshaling and unmarshaling in Go or Java, there doesn't seem to be validation to reject the duplicate keys so the first item with the duplicate key is simply overwritten when the second duplicate key is encountered. I know the JSON specification doesn't explicitly state that duplicate keys aren't allowed but even in the underlying JavaScript, duplicate keys are almost certainly an error
I'm currently working on implementing this specification in Go and the bigger issue is with the second sentence - there is no way to tell a {componentName}:{measurementName} from a simple unique string. The following ambiguities occur:
Since both componentName and measurementName are optional, you might end up with a composite key of either `` or:`` - both an empty string and a colon are valid keys in JSON but I think those should be avoided.
If only a componentName is present, should the colon be appended to this value?
If only a measurementName is provided, should the colon be prepended to this value?
If the answer to ambiguities 2 and 3 is no, how do I programmatically tell the difference between a simple string and a composite key that only contains a componentName or measurementName?
How do I programmatically tell the difference between a simple string that happens to contain a colon (or more than one colon) and a composite key?
In general, I think I like the idea of a key that has a semantic meaning so I'm in favor of continuing with the idea rather than just stating the key is a unique string.
In the The Checks Object section, the second paragraph reads:
The first sentence of this paragraph should be changed to read (emphasis only to highlight the changes):
The JSON structure that this specification describes will fail in many linters and languages if the keys are not unique. The linters I tried all show a
duplicate keyerror. When marshaling and unmarshaling in Go or Java, there doesn't seem to be validation to reject the duplicate keys so the first item with the duplicate key is simply overwritten when the second duplicate key is encountered. I know the JSON specification doesn't explicitly state that duplicate keys aren't allowed but even in the underlying JavaScript, duplicate keys are almost certainly an errorI'm currently working on implementing this specification in Go and the bigger issue is with the second sentence - there is no way to tell a
{componentName}:{measurementName}from a simple unique string. The following ambiguities occur:Since both
componentNameandmeasurementNameare optional, you might end up with a composite key of either`` or:`` - both an empty string and a colon are valid keys in JSON but I think those should be avoided.If only a
componentNameis present, should the colon be appended to this value?If only a
measurementNameis provided, should the colon be prepended to this value?If the answer to ambiguities 2 and 3 is no, how do I programmatically tell the difference between a simple string and a composite key that only contains a
componentNameormeasurementName?How do I programmatically tell the difference between a simple string that happens to contain a colon (or more than one colon) and a composite key?
In general, I think I like the idea of a key that has a semantic meaning so I'm in favor of continuing with the idea rather than just stating the key is a unique string.