Hello Joakim Thanks for your input, and sorry for the delay in my response. I have been on a longer vacation and not been able to answer all mail.
Emmanuel had the same misgivings in a later mail, to which I replied the following (copied from my response to Emmanuel, his questions/comments prefixed by *): * I am bit puzzled by having values listed as a sub-element of a <timestamp>. This is especially true since, for example, errors place the timestamp as an attribute of the <error> tag. What are the design decisions that led to this ordering? In some cases, there's only one field value per timestamp, so this might look strange. But in the general case, there are multiple field values for each timestamp in a meter. Examples: Water meters report (at least) Accumulated Volume & Momentary Flow for each timestamp. Electricity meters report (at least) Accumulated Energy and Power for each timestamp. Heat meters usually report (at least) Accumulated Energy, Accumulated Volume, Momentary Flow, Momentary Power, Supply Temperature, Return Temperature and Temperature Difference, for each timestamp. The main reason is to have a simple way to group together fields belonging together (by time). Otherwise, a long list of values would be provided, and the receiver would need to compare timestamps to know which field values belong together. Compressed, timestamps also require much memory compared to start/end element signals, and by placing the timestamp in a separate element, redundancy is avoided. * In the read-out from multiple devices, I would have preferred that the <field>s are placed as sub-element of the <node>. Ok. This would create redundancy in the timestamp part, as explained above. * Wouldn't it be more future-proof to have <historical*> field types represented by a field called <historical> with an attribute describing the period of the history? XEP-0326 contains an alternative way of reporting historical values stored in databases. The values shown here correspond to a momentary readout of a device, where the values have been flagged as historical. The period is described by the timestamp, and here you see the grouping feature of the timestamp element. Best regards, Peter Waher -----Original Message----- From: Joakim Eriksson [mailto:joak...@sics.se] Sent: den 19 januari 2014 17:44 To: XMPP Standards Subject: [Standards] XEP-323 timestamp I think that the XEP-323 timestamp is a bit strange. I would have a set of measurements or sensor data with an extra attribute / meta data which is the timestamp. But in XEP-323 is looks like the timestamp is the top node: <fields xmlns='urn:xmpp:iot:sensordata' seqnr='4'> <node nodeId='Device01'> <timestamp value='2013-03-07T19:00:00'> <numeric name='Temperature' ../> <numeric name='Runtime' .../> </timestamp> </node> </fields> So in this case is looks like the timestamp has a set of attributes that are temperatures, runtime, etc. which feels a bit strange. I think it would make more sense if it would be like this: <sensordata> <timestamp value='xxx'> <numeric ...> <numeric ...> <numeric ...> </sensordata> or (timestamp in the sensordata node) <sensordata timestamp='xxx'> <numeric ...> <numeric ...> <numeric ...> </sensordata> Best regards, -- Joakim Eriksson, SICS
