W3C home > Mailing lists > Public > public-wot-ig@w3.org > July 2016

Re: Stability and Current Practises

From: Christian Groves <Christian.Groves@nteczone.com>
Date: Mon, 11 Jul 2016 21:09:50 +1000
To: public-wot-ig@w3.org
Message-ID: <28c5c4d8-b606-38a8-30f8-04ee16fd1ffe@nteczone.com>
Hello Carsten,

 From the current practises document 
http://w3c.github.io/wot/current-practices/wot-practices.html clause :

"The stability field provides a hint for caching and polling. This value 
should also be included in the cache control information of protocols, 
e.g., the Cache-Control header field of HTTP or Max-Age option of CoAP."

This is the only description in the document of what stability is used 
for. So I think it is appropriate to consider its relationship to fields 
mentioned above. Sensors can support what event sampling rate they like 
but the assertion in the document is that this property is for caching 
and as you have mentioned for that application a limited resolution is 

Regards, Christian

On 11/07/2016 4:54 PM, Carsten Bormann wrote:
> Christian Groves wrote:
>> [CNG] I'm familiar with metrology, however the Cache-Control Max-Age is
>> defined to be a non-negative decimal integer. If the primary purpose of
>> stability option is to map to the cache control and http max-age then it
>> doesn't seem to follow that you make it a sub-multiple of a second.
> I don't agree with this premise.
> Indeed max-age has limited resolution, mainly for simplicity and because
> the benefit of caching in the network decreases with very low max-age
> values.
> But the stability attribute is not about mapping max-age values, it is
> about the data source itself.  If the sensor is designed to support a 4
> Hz control loop, a stability of 250 ms is quite appropriate.
> (A numeric implementation problem is that binary floating point values
> cannot exactly represent decimal fractions.  It can therefore make a
> non-trivial difference whether the base unit is seconds or, say,
> milliseconds.  If we assume that real-world sensor systems are using
> milliseconds as their time base and not "mibiseconds", i.e. 1024ths of a
> second.  And if we are stuck with binary floating point, which of course
> neither CBOR nor EXI are.)
>> It
>> means that for a given number of bits the time represented won't be the
>> same. 32bits of ms doesn't equal the same length of time as 32bit s.
>> Also it means the mapping is more complicated, e.g. is 1750ms mapped to
>> a Max-Age value of 1s or 2s? It can't be mapped to 1.75s.
> What is the use case for mapping between the TD stability values and a
> max-age value?
> In any case, the fact that max-age doesn't have a resolution that is
> appropriate for high-rate, low-latency communication doesn't mean that
> we are stuck with the limitations of this option for all applications.
> On the other hand, stability would be a more abstract TD attribute where
> it would be nice if it could span a wide array of applications.
> I should note that I don't have a strong opinion on the data type or
> base unit of the stability attribute; I just want to be sure that we
> consider the implications of any choice we make here.  (And that we
> don't make asymptotic errors such as choosing 0 for static.)
> Grüße, Carsten
Received on Monday, 11 July 2016 11:10:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 11 July 2016 11:10:34 UTC