[Fiware-ngsi] registerContext "update" with convenicence operations (was Re: NGSI9 registerContext "update" interpretation)

[Fermín Galán Márquez]

Dear Tarek,

Right, that is my interpretation. Note in http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_NGSI-9_Open_RESTful_API_Specification_%28PRELIMINARY%29#Convenience_Operation_Resources that if the URL includes {EntityID} it doesn't include {TypeName} and viceversa. So, in the case of {TypeName}, the only way to set the ID is a pattern.

Best regards,

------
Fermín

El 07/03/2013 18:39, t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk> escribió:
Hello Fermin,

Does it mean in this case that there is no EntityId for the Context(s) in question? Just ".*" with a type defined?

Best regards,
Tarek



From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: 07 March 2013 17:09
To: Tobias Jacobs
Cc: Elsaleh T Mr (Electronic Eng); fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: registerContext "update" with convenicence operations (was Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation)

Dear Tobias,

I think that at the end we agree on the semantics according to 1) (e.g. for the case of DiscoverContextAvailability https://forge.fi-ware.eu/plugins/mediawiki/wiki/fi-ware-private/index.php/OMA_NGSI_9/10_change_proposals#Proposal_10).

Regarding my second case

/contextEntityTypes/{typeName}/...

in fact, I have realized (thanks to Ken ;) that is directly mapped to the following EntityId:

  *   EntityId.id = ".*"
  *   EntityId.type = "{typeName}"
  *   EntityId.isPattern = "true"

Best regards,

------
Fermín

El 07/03/2013 10:56, Tobias Jacobs escribió:
Hi Fermin,

Yes, in general the convenience function should always be translatable into standard operation payloads.

I agree that the type cannot be specified when referring to an EntityId in the access URI. This would translate into a request without given type (type is optional in the EntityId).

So I think the main question is: what is the semantics of operations on entities without specified type. I see two possibilities, and I am in favour of the first one.

1)      When the type is missing, the operation is applied to all entities having the same Id

2)      Missing type is handled like a special type. So the operation is applied to all entities with the same Id for which no type is given.


Best
Tobias

From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Dienstag, 5. März 2013 19:25
To: Tobias Jacobs
Cc: t.elsaleh at surrey.ac.uk<mailto:t.elsaleh at surrey.ac.uk>; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: registerContext "update" with convenicence operations (was Re: [Fiware-ngsi] NGSI9 registerContext "update" interpretation)

Dear Tobias,

I've been reading in detail the binding draft (sorry for not doing in the first time :) and it is said (e.g section 3.1.3, also in other sections) that "Note that this operation [POST] can be used both for new registrations and for updates of existing registrations; in the latter case the request message should include the RegistrationId field". As far as I understand, for POST the combination of URL + registerProviderRequest data (described in  section 3.0.0.1) can be always translated to the payload of a registerContext stanard operations. Is is that correct?

However, I doubt in other aspect, regarding URLs. In particular, I see that there is a "famliy" of URLs that includes {EntityID}, e.g:

/contextEntities/{EntityID}

and other "family" that includes {typeName}

/contextEntityTypes/{typeName}/attributes/{attributeName}

Thinking in the mapping from URL + registerProviderRequest to a RegisterContextRequest payload (according to the registerContext standar operation), how do you determine the type to use (in the first case) and the ID to use (in the second case)? In the first case, the syntax of EntityId (section 5.5.5 in OMA spec) allows you to not include the type (type is optional); although it will limit you in the use of convenience operations. On the contrary, note that ID for entity is mandatory in section 5.5.5.

Best regards,

------
Fermín

El 04/03/2013 9:58, Tobias Jacobs escribió:
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<mailto:t.elsaleh at surrey.ac.uk>; 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

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:part25.05070406.07000909 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20130307/2f23fe22/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/20130307/2f23fe22/attachment.jpe>