Closed bkp7 closed 6 years ago
tkurki
commented
6 years ago If displayScale is present it must have both 'lower' and 'upper' as having just one is pointless:
I stopped to think about this a bit. Think about a graphical scrolling echosounder display: it is effectively an autoranging gauge that has "lower" set to 0 and it scales upper to a "nice" value that contains all samples in the time window.
Should we relax this so that either is mandatory, if the property exists?
bkp7
commented
6 years ago OK, yes and the autoranging, time series or sparkline type display could be used for all sorts of data.
However, the metadata/displayScale is applicable to a single discrete value, and a gauge (dial) cannot exist without having an upper limit. I am still minded that if present there should be both a lower and upper value set and sent by the server.
Perhaps we need to find a form of words which states that the consumer display must be able to show values within the range specified by lower and upper displayScale. Autoranging would meet that criteria. That looser wording would also allow a gauge to show a larger display scale. eg. a tacho with 0-4200 lower-upper might look better in some designs if the gauge went to 4500 or 5000. This would be a decision for the gauge designer.
tkurki
commented
6 years ago I think we are thinking too far ahead here and too much about a single detail / use case.
states that the consumer display must be able to show values within the range specified by lower and upper displayScale
The schema should have well known "homes" for different data items that are needed to support the real world use cases. Here the case is "we need a place to handle the min and max values for displaying a gauge". I think we are going in the wrong direction if we try to specify exactly how the user interface must behave.
bkp7
commented
6 years ago Agreed with the fundamental issue: "we need a place to handle the min and max values for displaying a gauge".
Apart from a few gauge designs, both values are required to render a gauge, that is why I propose that both must be present in the data (if either is). That doesn't mean they both have to be used by the consumer. If you allow only one value to be present you are making assumptions at the sensor/server end about what type of gauge will be rendered by the consumer.
However, if the view is that it should be changed to allow either I'll make the changes so we can put this one to bed.
tkurki
commented
6 years ago We are arguing a pretty fine point here, I'm good with both being required.
I'd prefer no spaces in filenames.
I read through the titles and descriptions and thought about my argumentation above. I'd prefer wording that talks less about a gauge and more about the display preferences, be it a dial gauge or for example an axis of a graph. But we can move forward with this as well.
Resolves issue #406.
Schema modified so that 'displayScale' is optional (all existing tests pass unaltered). For versioning this constitutes an ADDITION so bumps the schema by x.x.+1.
If displayScale is present it must have both 'lower' and 'upper' as having just one is pointless:
Both Upper and Lower must be numeric:
No other properties allowed within displayScale