[Fiware-ngsi] NGSI10 updateContext response interpretation

[Tobias Jacobs]

Hi Fermin,

Thanks for initiating these discussions!

I have not even thought before about the possibility to update whole sets of Entities by the usage of patterns in the updateContext operation.

But when I think about it, I would not make it mandatory to send back an explicit list of Entities that 'exist' in the System, but I would rather send back the pattern EntityId with a statuscode acknowledging the receipt of the update. The reason is that it cannot be assumed in general that the recipient of the update operation maintains some database of entity information - e.g. the IoT Broker does not have that at the moment.
Still sending back a list of non-pattern entity IDs could be something optional.

Best regards
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: Donnerstag, 28. Februar 2013 09:55
To: fiware-ngsi at lists.fi-ware.eu
Subject: [Fiware-ngsi] NGSI10 updateContext response interpretation

Hi,

The updateContext operation (OMA specification 5.4.6) includes a ContextElementResponse list in the response. We think that a list of ContextElementResponses makes full sense in the case of queryContext, but it is a bit strange in the case of an update operation except if the purpose is to acknowledged in some way that the update operations in the individual entities have been successfully completed or not. In this sense, our proposal is as follows:

  *   For each no pattern entity (i.e. isPattern=false) in the ContextElement list in the request, a ContextElementResponse is included in the response, that shall include:
     *   A ContextElement that includes the entity (isPattern=false) and attributes in the corresponding ContextElement in the request, but not the attribute values (it doesn't make sense to return the values, as the client sending the updateContext request already know them).
     *   An StatusCode with the result (success or failure) of the processing of the ContextElement update
  *   For each pattern entity (i.e. isPattern=true) in the ContextElement list in the request, N ContextElementResponses are included in the response (as many as matching entities), each one shall include:
     *   A ContextElement that includes the entity (isPattern=false) and attributes in the corresponding ContextElement in the request, but not the attribute values (it doesn't make sense to return the values, as the client sending the updateContext request already know them).
     *   An StatusCode with the result (success or failure) of the processing of the ContextElement update

For example, considering that the NGSI server has the following data:

  *   Entity R1 with attributes A=1, B=2, C=3
  *   Entity E1 with attributes A=5, B=10, C=22
  *   Entity E2 with attributes A=7, C=100

(I'm omitting types in entities and attributes as they aren't relevant for the example).

Let's consider the following updateContext request with 2 ContextElements and updateAction = UPDATE:

  *   CE1:
     *   Entity: R1 (isPattern=false)
     *   Attribute: A=30
  *   CE2:
     *   Entity: E.* (isPattern=true)
     *   Atttribute: B=40

The response will include 3 ContextElementResponses, in the following way:

  *   CER1:
     *   CE
        *   Entity R1 (isPattern=false)
        *   Attribute: A
     *   StatusCode="Ok"
  *   CER2:
     *   CE
        *   Entity E1 (isPattren=false)
        *   Attribute: B
     *   StatusCode="Ok"
  *   CER3:
     *   CE:
        *   Entity E2 (isPattren=false)
        *   Attribute: B
     *   StatusCode="Not found"

What do you think?

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/20130301/5e1c9362/attachment.html>