[Fiware-ngsi] NGSI10 updateContext response interpretation

[Rolando Sergio (Guest)]

Hi Tobias, hi Fermin,
I completely agree with Tobias about perplexity on updateContext with pattern entityIDs, which does not seem to be very useful and raises complications in implementation too.
Furthermore, it implies to accept pattern entityIDs also in queryContext responses, since the Pub/Sub does not know the specific entityIDs which the pattern refers to (e.g. updateContext for "urn:username:abc*" followed by queryContext for "urn:username:*"). In the end, the requiring client will not know what (and how many) the real entityIDs are, and I think it is rather odd.
I have always considered patterns "only" a simple way to collect data for clients requiring context or subscribing to it.

>From my point of view, I would suggest to leave out pattern support on entityIDs in updateContext, except if there are specific requirements from use cases (and they cannot be faced otherwise :)).

Best regards,
Sergio

________________________________
From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs
Sent: lunedì 4 marzo 2013 10.31
To: Fermín Galán Márquez
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI10 updateContext response interpretation

Hi Fermin,

I do not have a strong opinion on whether or not to allow ContextUpdate operations with EntityID patterns. I do not see a convincing use case where this is needed, but still there might be.

I still think that "OK" could be used for the statuscode; what "processed correctly" means anyway depends on the component which exposes NGSI 10. If I think for example of a component that just dumps every contextUpdate in a database and starts looking for suitable information when a queryContext comes, this component would not even distinguish between updates of single entity Ids and updates of pattern Ids.

Best regards
Tobias

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Freitag, 1. März 2013 16:37
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI10 updateContext response interpretation

Dear Tobias,

If I understand you correctly, considering the examples request I propose and your alternative, the response would be the following one:

 *   CER1:

    *   CE

       *   Entity R1 (isPattern=false)
       *   Attribute: A

    *   StatusCode="Ok"

 *   CER2:

    *   CE

       *   Entity E.* (isPattern=true)
       *   Attribute: B

    *   StatusCode=<ACK>

Is that correct?

In this case, we should find the appropriate value for the <ACK> status code. I think we cannot use "OK", because its semantic implies that the update has been not only received but also processed correctly. I have look to the table in section 5.5.14, but no one of the the codes there seems to be suitable for an ACK semantic... Looking to HTTP (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes) maybe "202 Acepted" could be used for this.

There is another posibility: that the NGSI doesn't allow isPattern=true in updates at all. In this case, we can use "501 Not Implemented".

What do you think?

Best regards,

------
Fermín

El 01/03/2013 9:29, Tobias Jacobs escribió:
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> [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<mailto: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

________________________________

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/20130304/e33c4b8f/attachment.html>