Hi Thiago, Drarka, Uze, Thanks for the clarifications.
Does that mean the receiving end should take the type attribute from CBOR data stream as a reference, and interpret the properties with flexibility? If any floating point number with no fractional part can be transmitted as an integer, how about a boolean value? should the receiving end interprets integer 0 as 'false' and non-0 as 'true' like C/C++ does? For example, the properties [true, false, 0, 1, 10, 10.0, 10.1] will be transmitted in CBOR stream as: 87 # array(7) f5 # primitive(21) - true f4 # primitive(20) - false 00 # unsigned(0) - integer 0 01 # unsigned(1) - integer 1 0a # unsigned(10) - integer 10 f9 4900 # primitive(18688) - number 10.0 fb 4024333333333333 # primitive(4621875412584313651) - number 10.1 when the receiving end invokes IoTivity API OC::OCRepresentation::getValue() to get the property values, do we need to convert these primitives to the desired types? Best Regards, Tonny On Sat, Nov 19, 2016 at 8:59 AM, Thiago Macieira <thiago.macieira at intel.com> wrote: > Em quarta-feira, 16 de novembro de 2016, ?s 19:47:07 PST, Dwarkaprasad > Dayama > escreveu: > > OCF enforce data type for each resource / property very specifically. > > > > For luminance sensor it is supposed to be floating point value and not > the > > integer. > > We've been through this. > > Any floating point value that has no fractional part can be transmitted as > an > integral on the wire. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161119/31d3fc7b/attachment.html>
