Re: [Standards] XEP-323 timestamp

[Joakim Eriksson]

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:joak...@sics.se]
Sent: den 20 februari 2014 13:12
To: Peter Waher; XMPP Standards
Cc: joak...@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: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

-----
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