Should be the CB more flexible with dates/geo types allowing nulls/""?

[fgalan]

Allow "" and null in DateTimes/ISO8601 and geo:xxx. This would be easier the life for clients.

[mrutid]

There are (real) situations where you don't have a specific date or location for an attribute. Right now it is necessary to DELETE the attribute itself in order to manage this scenario (and it implies to develop non-trivial and special behaviours in GUI and FORMS for these two types) It would be nice to allow empty/null values for these types.

[jmcanterafonseca]

NGSI-LD does not allow nulls. You can always define a dummy location (empty object) or dummy date (1st Jan 1970) to flag an unknown value ...

[fgalan]

You may have wrong reports or analytics if you use dummy dates, locations (or dummy data in general) or you will need special processing to adapt reports to your "dummy data conveys". NULL has a clear, global, common semantic (and wide system/framework support) and IMHO is a good value to express "void/unknow".

So in NGSI_LD what would you plan to use as an "unknown" integer value? will it be 0? -99999?... it will be difficult to make analytics with that fake data.

Anyway we can discuss this NGSI-LD particularity, and the interoperability options with NGSIv2, when it start the merging process.

[jmcanterafonseca]

my point is that if something is not known why it should appear as an Attribute value of an Entity at a particular point in time?

for instance, if a device is not available or is out of service then in that case an IoT Agent should not be updating anything to the CB, and let the value as it was before (either non-present or with its previous value).

[fgalan]

my point is that if something is not known why it should appear as an Attribute value of an Entity at a particular point in time?

To make easier the life for clients, as my first entry in the issue tells :)

I mean, ideally, it can be as you said so if the client doesn't have the data, it doesn't send an attribute with it. But some clients (due to they have "fixed" the attributes they send and cannot omit them, I understand IOTAs are of that kind generally) cannot do that, and, in that case, null seems to be a good option from a semantical point of view.

[jmcanterafonseca]

maybe the IoT Agents should be fixed. It provides a more useful insight the old value of an Attribute than overwriting it with null ... due to a failing sensor ....

[fgalan]

Related question at SOF (to be edited once this issue gets addressed): https://stackoverflow.com/questions/59642299/orion-context-broker-geolocation-how-to-deal-with-location-not-known

[fgalan]

PR #3846