[Fiware-ngsi] Using registerContext "update" to delete registrations (it was Re: NGSI9 registerContext "update" interpretation)

[Fermín Galán Márquez]

Dear Tobias,

I have updated the wording in the wiki, hoping that now it will be ok with you.

Regarding your proposal to delete, I have checked that you are right, EntityIdList is optional in ContextRegistration (see section 5.5.7 in OMAC spec). So, if I'm understanding correctly, you are proposing to use the following registerContext "update" to delete a registration:

  *   RegisterContextRequest:
     *   RegistrationId of the registration to be deleted
     *   Duration -> omitted
     *   ContextRegistrationList with 1 element, which is a ContextRegistration with the following fiedls:
        *   EntitiyIdList -> omitted
        *   ContextRegistrationAttributes -> omitted
        *   RegistrationMetadata -> omitted
        *   ProvidingApplication -> ?? (from a syntactical point of view, this is a mandatory field, what to include?)

Is that correct?

The need to include ProvidingApplication it is a bit dirty from my point of view, but it is difficult to do figure out another way... Another alternative (that I think it has been discussed before in the list) is to set "duration = 0" to mean that the registration has to be canceled (in this case, the content of ContextRegistrationList will be ignored). What do you think?

Best regards,

------
Fermín

El 05/03/2013 13:56, Tobias Jacobs escribió:
Hi Fermin,

Replacing “message” by “request” is indeed more correct. I would prefer to keep “context registration” as in my view it makes less assumptions about how the NGSI9 server processes the registration, but I am not insisting on it.

OK, so for deletion one still needs to provide a contextRegistration instance, but with no entities inside, right?
Anyway the deletion is just an informative example, so we can as well not write that sentence.

Best
Tobias

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Dienstag, 5. März 2013 09:13
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

Dear Tobis,

Yes, you are right... I refer to 5.3.1.

Regarding you wording proposal, I'm ok with the first sentence (with two slight changes):

"Whenever in the RegisterContext request a RegistrationId is present, then any previous ContextRegistrationList under the same id is replaced with the one in the current request."

However, not sure if the second sentence is right. In 5.3.1.1 is stated that ContextRegistrationList is a mandatory field and that it's cardinaly is [1..unbounded] so at least one ContextRegistration must be present in each registerContext request, there is no possiblity of a "empty ContextRegistrationList". What do you think?

Thanks for the feedback!

Best regards,

-------
Fermín

El 04/03/2013 9:42, Tobias Jacobs escribió:
Hi Fermin,

About proposal 6:

a)      Probably you want to add the text to 5.3.1, not to 5.3.2?


b)      Can we replace the text

“
The processing of a registerContext in which a RegistrationId is present (assuming that the given RegistrationId is known by the NGSI9 server) the Context Registration list in the request will replace the previous Context Registration list associated to the given RegistrationId.
“

with the following text:
“
Whenever in the RegisterContext message a RegistrationId is present, then any previous context registration under the same id is replaced with the one in the current message. Therefore, deleting an association is possible by a RegisterContext operation with the respecting RegistrationId and an empty ContextRegistrationList.
“

Best
Tobias


From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Freitag, 1. März 2013 15:57
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation

Dear Tobias,

Thanks for the feedback. I have added a "Proposal #6" entry in https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_9/10_change_proposals#Proposal_6, so you can add your name to the "Supporters" field if you want.

(Of course, this also applies for the previous 5 proposals and for everyone in the list that want to support them :)

Best regards,

------
Fermín

El 01/03/2013 9:11, Tobias Jacobs escribió:
Hi Fermin,

Yes, I would agree that the update of a registration should completely replace the previous version of the same registration, as here there are no updateActionTypes defined like in NGSI 10.

By the way, an analogous question is the notifyContextAvailability operation, where for a given subscription id a number of registrations are specified. Also here the registration information specified in the notifyContextAvailability operation should completely replace the previous registration information this particular subscription.

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: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:part9.09040007.08060106 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

________________________________

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