[Fiware-ngsi] NGSI9 registerContext "update" interpretation

[Fermín Galán Márquez]

Dear Tarek,

First of all, let me clarify that the scope of my case, interpretation and solution is only standard operations.

Regarding convenience operations, looking to http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-9_Open_RESTful_API_Specification_%28PRELIMINARY%29#Convenience_Operation_Resources it seems that NGSI9 convenience POST operations only takes into account the creation of new registrations (i.e. new regIds) not updates (which is ok with me, as the update case can be complex, so it is better to update always using standard operations). However, I'm not an expert on NGSI (our Context Broker don't support them yet), so probably other people could provide better feedback on this.

Best regards,

------
Fermín


El 28/02/2013 12:39, t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk> escribió:
Hello Fermin,

I am stuck myself on this point on how to update NGSI-9 Entities. At the moment I have no objection to your approach.

But how would updating be done wrt POST:


·          "http://..........entityID/AttributeDomainName"

·         "http://..........contextEntityType"

·         "http://..........contextEntityType /AttributeDomainName" ?

Best regards,
Tarek



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: 28 February 2013 08:47
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

Hi,

OMA specification section 5.3.1 doesn't specifies how the Context Registration list has to be processed in the case of a registerContext "update" (i.e. a registerContext in which RegistrationId is present).

Our proposal is to interpret this case in the following way:

  *   The Context Registration list in the request replaces the previous Context Registration list associated to the given RegistrationId.
Follows an illustration on how it works for two example cases:

[cid:part2.05040408.09060302 at tid.es]

Compared with other alternatives (e.g. that the Context Registration list in the request would be added to the ones already associated to the given RegistrationId), our approach allows a full control of the elements associated to the RegistrationId. We can assume that the client sending the registerContext "update" knows the previous status of elements associated to the given RegistrationId, so it can control which exact Context Registration elements he wants to have after the update is processed. In fact, the solution based on replacing is the only way of removing elements already existing.

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/20130228/f184e685/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 29028 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130228/f184e685/attachment.jpe>