[Standards] XEP-323 timestamp

Joakim Eriksson joakime at sics.se
Thu Feb 20 19:01:01 UTC 2014


Hello Peter,

Comments, below.

Peter Waher skrev 2014-02-20 19:45:
> Hello Joakim.
>
> Regarding your concerns:
>
> 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.
>
> Correct. All this is part of the xs:dateTime data type, which is more
> fully described in XEP-0082 (XMPP Date and Time Profiles).
>
> 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>
>
> Naming at this point is just a matter of taste it seems. Sensordata
> sounds like a top-node, which timestamp is not. Envelope conveys no
> meaning. In my ears timestamp sounds better. But it just a matter of
> taste. Too many implementations in the field now, to change naming.
> Needs heavier arguments than taste at this point to change the name.

But the standards are still in early drafts, so from my perspective it
is much more important with good easy to understand naming and a slim
XEP than already counting number of implementations?!

My implementation is confusing so I would be very ready to both fix
the XEP and fix the implementation ;-)

> 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.
>
> It is not a top-node. It’s at level 3 in a 4 level hierarchy:
> fields/node/timestamp/field.

Well it is a "top-node" for the sensor data fields which is to
me not a good thing. It might be a bit "academic" to consider clean
naming to be a more important thing than number of implementations
but that is my perspective.

Best regards,
-- Joakim Eriksson

> Best regards,
>
> Peter Waher
>
> 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 <mailto: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 <http://www.avg.com>
>
>  > Version: 2014.0.4259 / Virus Database: 3705/7100 - Release Date:
>
>  > 02/17/14
>
>  >
>
>  >
>
> -----
>
> No virus found in this message.
>
> Checked by AVG - www.avg.com <http://www.avg.com>
>
> Version: 2014.0.4259 / Virus Database: 3705/7109 - Release Date: 02/20/14
>
> -----
>
> No virus found in this message.
>
> Checked by AVG - www.avg.com <http://www.avg.com>
>
> Version: 2014.0.4259 / Virus Database: 3705/7100 - Release Date: 02/17/14
>




More information about the Standards mailing list