Hello Joakim
I'll address your concerns one at a time: So a resource limited device that can not translate between Fahrenheit and Celcius will be able to provide and parse the control forms? Yes, in the general case. Temperature and two units is of course a trivial example, but the extension tries to solve the general case, which is much more complicated. Furthermore assembling control forms is easy, parsing them is often supported directly in the XMPP client library already provided. From my perspective (being a resource constrained device software developer) I would prefer a more lightweight approach than the control forms to discover the fields and their range, units, etc. An additional approach might be possible. However, it would not remove the need for control forms (see below). A complete slimmer "discover fields" response could be: ... <fields> <int name='Temperature' min='-40' max='95' unit='C' /> <int name='Humidity' min='0' max='100' unit='%' /> </fields> ... Now, sensor data (XEP-0323) can publish a lot of records, not all controllable. Normally, only a small fraction of published fields would be controllable. Furthermore, many controllable parameters would not be readable (and therefore not available as fields through XEP-0323). So there’s no natural connection between fields in XEP-0323 and control parameters in XEP-0325 in the general case. Secondly, your example only include ranges. Intervals is just one validation method. Control forms provide more. The pluggable validation structure (i.e. using sub-elements) provides a more general way to defining limits than attributes on an element would. Thirdly, by supposedly including this information in the field information, it would have to be sent every time the sensor is read, and stored with the values as well. A control form can be read once to know the capabilities of the device. When somebody wants to know the control capabilities of a device, it simply reads the form. It can later issue control commands without reading it beforehand. Then if it is for humans - all the labels and other things could be included? Is the current forms mechanisms intended for machine-to-machine or machine-to-human? It is intended to be used by both machines and humans. Sufficient meta-data has been added to create an interface that can both be automated as well as be understood by humans with no device-specific software added, and taking into account aspects important for both. Best regards, Peter Waher Peter Waher skrev 2014-01-15 16:22: > Hello Joakim > > The control form provides means to publish limits for control values. See > §3.3.1 for examples. > > Best regards, > Peter Waher > > -----Original Message----- > From: Joakim Eriksson [mailto:[email protected]] > Sent: den 15 januari 2014 08:51 > To: [email protected]<mailto:[email protected]> > Subject: Re: [Standards] XEP-323 vs XEP-325 > > Tomasz Sterna skrev 2014-01-15 11:54: >> Dnia 2014-01-14, wto o godzinie 11:30 +0100, Joakim Eriksson pisze: >>> <double name='DesiredRoomTemperature' value='22.0'/> ... >>> I can understand omitting unit and momentary [...] >> >> I can't understand omitting the unit. >> You need to know up front what unit does the control expect. >> >> There's a room for misinterpretation and mistakes like ie. >> frying/freezing your plants. >> >> When you specify the unit, at least you give a chance to err-out on >> unhandled unit if the control is unable to convert. > > Yes, keeping the unit even for control make it possible for the controlled > object so do better error control and "sanity checking". > > Is there a good way to inform the controller what are the limits of the > values? E.g. max and min values of the desired room temp? > (have not yet fully read all the XEP-323/325, etc). > > Best regards, > -- Joakim Eriksson, SICS > ----- No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2014.0.4259 / Virus Database: 3658/6960 - Release Date: 12/30/13 Internal Virus Database is out of date.
