[Fiware-ngsi] Interpretation for EntityIdList field in subscribeContext NGSI10 operation

[Tobias Jacobs]

Hi Fermin, all,

I agree with your proposal. I see no reason why redundant information should be included in the notifications.

Best regards and sorry for the late reply
Tobias

From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Fermín Galán Márquez
Sent: Freitag, 26. April 2013 17:33
To: fiware-ngsi at lists.fi-ware.eu
Subject: [Fiware-ngsi] Interpretation for EntityIdList field in subscribeContext NGSI10 operation

Hi,

We have found (other :) ambiguity in NGSI spec that we think it could be useful to discuss in the mailing list:

According to OMA spec 5.4.2, the subscribeContext operation allows to specify a list of 1 to N entities (EntityIdList field) which is defined as a "List of identifiers of the Context Entity(ies) for which the Context Information is requested".

However, it is not clear which subset of those 1 to N entities has to be included in the notifyContextRequest associated to a given subscription. Let's analyze case by case:

  *   ONTIMEINTERVAL conditions: it seems to be clear that all the N entities have to be notified in a regular time basis. There is no way considering a subset of the N entities in this case.
  *   ONCHANGE and ONVALUE conditions: in this case notifyContextRequest are always due to an updateContext request and we see two alternatives:
     *   All the 1 to N entities are included in the notifyContextRequest
     *   Only the subset of "triggering entities" is included, meaning by "triggering entities" the ones which attributes match the ONCHANGE or ONVALUE condition.

Let's consider an example to clarify the differences between interpretation 1 or 2. Assume the following subscription is in place.

  *   EntityIdList: E1, E2, E3, E4
  *   NotifyCondition ONCHANGE on attribute A

Let's consider the following update is received: updateContext (E2-attribute A = X, E4-attribute B = Y). Thus:

  *   According to 1, notifyContextRequest would include E1, E2, E3 and E4
  *   According to 2, notifyContextRequest would include E2 and E4 as change in A only happens in these two ones.

A similar issue happens with subscribeContextAvailability and notifyContextAvailabilityRequest (in fact, subscribeContextAvailability subscription in NGSI9 has a logic that is pretty similar to subscribeContext ONCHANGE in NGSI10).

In our opinion, alternative 2 probably suits better to use cases. For example, consider that the NGSI server is controlling information of 1,000 sensors sensor1, sensor2, ... sensor1000 and that a given context consumer application wants to subscribe to "changes in the information of any sensor". The natural way of doing this seems to use one subscribeContext to the pattern "sensor.*". Then, if a change happens in e.g. sensor234, the consumer application wants only the information for sensor234 in the notifyContextRequest it received, not a huge notifyContextRequest with the information for the 1,000 sensors.

What do you think?

Thanks!

Best regards,

------
Fermín

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130503/3e0b0f67/attachment.html>