[Standards] XEP-323 timestamp

Joakim Eriksson joakime at sics.se
Thu Feb 20 18:24:29 UTC 2014


Hello,

The first part of the timestamp node is a timestamp, but in
my perspective a node in XML should contain information
that describe the node. E.g. a timestamp node should contain
information about the timestamp. Precision, time-zone, etc, etc.

I would go for an "envelope node" that contain some information.
I could be called sensordata since it is contains sensordata.
Then this timestamp correspond to a timestamp of the content of
the sensordata "envelope".

<sensordata timestamp="timestamp">
  ....
</sensordata>

For me this is much more clear than calling the top-node timestamp
and then add things in the timestamp. Would be like writing the letter
within the timestamp instead of timestamping the letter.

Best regards,
-- Joakim


Peter Waher skrev 2014-02-20 18:04:
> Hello Joakim.
>
> Thanks for your input.
>
> Regarding the name: After all, it is a timestamp, so "timestamp" does not
> sound too bad: http://en.wikipedia.org/wiki/Timestamp
>
> The hierarchy of the response is:
>
> <fields> / <node> / <timestamp> / <FIELD_TYPE>
>
> We've used the abstract term field to denote one item of information.
> <fields> is the collection of fields. The data can be seen as represented by
> a cube with three axes: Node ID, Timestamp, Field Name, each axis is
> represented by an element and a level in the hierarchy.
>
> Best regards,
> Peter Waher
>
>
> -----Original Message-----
> From: Joakim Eriksson [mailto:joakime at sics.se]
> Sent: den 20 februari 2014 13:12
> To: Peter Waher; XMPP Standards
> Cc: joakime at sics.se
> Subject: Re: [Standards] XEP-323 timestamp
>
> Yes, the grouping is reasonable, but the name of the XML node "timestamp" is
> what is not good.
>
> What about just renaming it to <sensordata> instead of <timestamp>?
> (or anything else but timestamp ;-)
>
>
> Best regards,
> -- Joakim
>
>
>
> Peter Waher skrev 2014-02-20 15:28:
>> 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:joakime at 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
>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4259 / Virus Database: 3705/7100 - Release Date: 02/17/14
>
>




More information about the Standards mailing list