[Fiware-ngsi] NGSI9 registerContext "update" interpretation

[Tobias Jacobs]

Hi Fermin,

In this case I would rather say that also update of registration is possible using POST. As the NGSI 9 specs define only one operation for registering new and updating registrations, I think it is natural to assume the same for the convenience functions.

Another reason are the design principles of the convenience functions. They were designed so that they can easily be translated into standard NGSI operations, without the need for checking if certain conditions are satisfied. If updating registrations are disallowed, then it needs to be checked if that registration already exists, and there is not even a functionality defined for that check in NGSI.

Best regards
Tobias

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Freitag, 1. März 2013 16:04
To: t.elsaleh at surrey.ac.uk; Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

Der Tarek, Tobias,

After looking to https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi9-RestfulBinding-Draft.docx, I interpret that convenience operations are ok to create new registrations (using a "familiy" of POST methods), but not for updating (significantly, the PUT method is not allowed). That is ok with me, as I think that general update of a registration is a complex case that probably doesn't make sense for convenience operations (thus, in the case of a client needs updating a registration, use standard operation registerContext)

@Tobias: could you confirm that NGSI9 convenience operations cannot be used to update registrations? (I asking directly because I guess you were one of the authors of the Ngsi9-RestfulBinding-Draft.docx document :)

Thanks!

Best regards,

------
Fermín

El 01/03/2013 11:31, t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk> escribió:
Hello Tobias,

The registerProviderRequest look very similar to the registerContextRequest. Is there any difference? I couldn't find it in the xsd or the examples in the SVN.

Although, my question was rather, HOW do we handle with an update (convenience) request when an "contextEntityType" is pointed to rather than "entityID" in the URL?

Has this been analyzed yet? Has anyone gotten to this stage yet? Tobias, have you already implemented operations related to UPDATING?

Best regards,
Tarek



From: Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: 01 March 2013 08:46
To: Elsaleh T Mr (Electronic Eng); fermin at tid.es<mailto:fermin at tid.es>
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

Hi Tarek,

Have you checked the binding document?
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi9-RestfulBinding-Draft.docx

This specifies a message body called registerProviderRequest, which might be what you are looking for.

Best
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 t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>
Sent: Donnerstag, 28. Februar 2013 12:39
To: fermin at tid.es<mailto:fermin at tid.es>
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

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<http://..........contextEntityType%20/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:image001.jpg at 01CE18BE.007F7910]

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/20130304/1fe7b664/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29028 bytes
Desc: image001.jpg
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130304/1fe7b664/attachment.jpg>