Subject: [core] Base value for SenML

From: Ari Keränen <[email-masked]>
Date: Tue, 20 Oct 2015 16:49:19 +0000

Hi CoRE WG folks,

Currently the base object for SenML allows defining a base name (to be prepended on all entry names), a base time (to be added to all entry times), and a base unit (a "default unit" if one is not defined in entry).

Now the question is should we also have "base value" that would be used as a default when an entry does not have any value?

This could be useful for example in a case where there is a ton of measurements with exactly same value and only very few differing values. Then, one could define e.g., just different time or name for all entires and leave the value part out completely when it is equal to the base value.

This seems to make sense and would apparently require only fairly small modifications in the draft. If we want to do this, we should most likely call that new base value "bv" and then rename the "boolean value" to "vb" -- and for consistency change "string value" to "vs".

Opinions?

Cheers,
Ari

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Oct 2015 21:47:14 +0200

> Now the question is should we also have "base value" that would be used as a default when an entry does not have any value?

Actually, just like bn and bt, we should enable the new bv to be
additive: it should be possible to have (numeric) value fields relative
to the base value.  (Since there may be different sensors in the time
series, it might even be useful to have multiple base values.)  While I
don't have a specific proposal, this meaning of base values would also
cover most of the desire for delta encoding.

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 20 Oct 2015 22:19:36 +0200

On Tue, Oct 20, 2015 at 04:49:19PM +0000, Ari Keränen wrote:
> Currently the base object for SenML allows defining a base name (to be
> prepended on all entry names), a base time (to be added to all entry
> times), and a base unit (a "default unit" if one is not defined in
> entry).

This would be consistent with the other attributes (to the point where
it could lead to a simplification of the phrasing in the specification),
and handy for everything that has a default or idle state. (E.g. batches
of actors most of which are in a common on or off state).

> This seems to make sense and would apparently require only fairly
> small modifications in the draft. If we want to do this, we should
> most likely call that new base value "bv" and then rename the "boolean
> value" to "vb" -- and for consistency change "string value" to "vs".

With the current model, it seems to me that we'd need base values for
each of the typed values (bvs, bvb, bv), of which exactly one may be
present, and that becomes the default in absence of any vX in the event
record. (Or, as Carsten suggested, the starting point for that).

Alternatively, we might want to consider dropping the explicit typing
information at altogether and have a single "v" (with "bv" as base). The
draft doesn't contain a rationale on it -- why are there distinct
attributes at all for what is in my impression modelled as one property?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 Oct 2015 22:34:51 +0200

> attributes at all for what is in my impression modelled as one property?

(That wasn't clear to me either -- if they are mutually exclusive as
they are today, the information is already in the type of the value.)

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Thu, 22 Oct 2015 11:14:07 +0000

>they are today, the information is already in the type of the value.)

One benefit is that if you do not recognize the type, or don't want your
parser to be aware of / need to check all the existing types for some
other reason, you can still have sensible way to parse the data since you
will know how to parse based on the *v member name.

And perhaps some future data type might want to be flexible on how to
present the data, case by case? This could be a bad idea too though.

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Thu, 22 Oct 2015 11:21:02 +0000

On 20/10/15 22:47, "Carsten Bormann" <[email-masked]> wrote:

>Ari Keränen wrote:
>> Now the question is should we also have "base value" that would be used
>>as a default when an entry does not have any value?
>

I like this idea. We could have "additive" feature for numeric values,
concatenating or "default" (i.e., replace) for string values, and
"default" for boolean and binary blob.

One thing to consider with additive approach is over and underflow, but
that actually already applies to base time (should probably comment that
in the draft).

Cheers,
Ari

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Oct 2015 13:32:58 +0200

> will know how to parse based on the *v member name.

Hmm, to get through the JSON, you still need to be able to parse instances of the type.

> present the data, case by case? This could be a bad idea too though.

Maybe we should be more explicit about the extensibility of the measurement map.
But that is kind of orthogonal to the question whether text string measurements and numeric measurements need different map keys (you already do not separate integer and float measurements, which may be a big difference for some implementations).

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 22 Oct 2015 13:57:16 +0200

> that actually already applies to base time (should probably comment that

... and precision! (Think different float sizes, or mixed
fixed-point-decimal and floating-binary systems).

I don't have high hopes that SenML can prescribe how to deal with those
situations, but implementors should be aware at least.

Best regards
Christian

---

From: Ari Keränen <[email-masked]>
Date: Thu, 22 Oct 2015 13:23:42 +0000

>Hmm, to get through the JSON, you still need to be able to parse

Actually, I meant that if you don't recognize the unit (which is bound to
a data type).

But yes, recognizing between string, boolean, and number is actually
pretty straightforward and need to be done anyway. So single type should
work from that perspective. If we want to add base64 encoded binary, then
telling that apart from a string might be trickier.

>But that is kind of orthogonal to the question whether text string
>measurements and numeric measurements need different map keys (you
>already do not separate integer and float measurements, which may be a
>big difference for some implementations).

What kind of explicit information you had in mind? Currently we simply say
you ignore the stuff you don't recognize.

Cheers,
Ari

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Oct 2015 15:52:35 +0200

> you ignore the stuff you don't recognize.

Well, the word "ignore" only appears in the senml+json IANA
considerations in the current draft; I must admit that wasn't the place
I was looking for it.

No word about how this is on the XML side.  The Relax NG schema, as
usually interpreted, is open to attributes at least from other name
spaces, but I would expect W3C schema implementations to choke on
unrecognized attributes.

(There is a little nit in the RNC with the reference to p*, which trang
announces as:
senml2.rnc:13:6: error: reference to undefined pattern
What is that mysterious p?
)

Grüße, Carsten

---

From: Ari Keränen <[email-masked]>
Date: Thu, 22 Oct 2015 14:05:06 +0000

>What is that mysterious p?

Good points and should be clarified in the next revision of the draft.

For the p* I have to defer the question to my co-authors. Cullen is
probably the best one to answer.

Cheers,
Ari

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 27 Oct 2015 05:51:30 +0000

Some version people were using p for something but I forget what now. I can go back and track that down at some point but I don’t think it was something that we felt had enough value to add to the spec so I suspect it was just “cruft” that got left in the trang. 

> On Oct 22, 2015, at 11:05 PM, Ari Keränen <[email-masked]> wrote:
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 27 Oct 2015 05:54:11 +0000

The most important thing about this is for it to be insanely simple, particularly at the server side where you are trying to process lots of readings.

We could do this but it just sounds complicated and I’m not seeing a really good driving use for this. I think I would rather not. (or at least I need to learn more about why we would want to add this complexity) 

> On Oct 21, 2015, at 1:49 AM, Ari Keränen <[email-masked]> wrote:
> 
> Hi CoRE WG folks,
>