[Fiware-ngsi] Clarification on NGSI10 binding document section 3.1.2

[Tobias Jacobs]

Hi Fermin,

I support the idea of allowing simpler systems without value ids, but I would like to avoid introducing new inconsistencies.

What if previously multiple instances of attribute values have been sent; will they all be overwritten, or is there some 'default id' attribute value which represents all updates without id, or should we leave the exact semantics of the operation open?

Best
Tobias

From: 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. November 2013 12:37
To: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] Clarification on NGSI10 binding document section 3.1.2

Hi,

After having not received negative feedback, I understand my document change suggestion is fine. Thus, if nobody opposes, I will modify the document and upload new version to SVN by tomorrow EoB.

Thanks!

Best regards,

------
Fermín

El 25/11/2013 17:03, Fermín Galán Márquez escribió:
Dear Tobias,

The specific reason is that the user doesn't need to use ID if he/she is using entities in which each attribute has a different name (so there is no need to use ID to distinguish between them). In this case, forcing users to have an ID would be overhead for them and users would tend to use the corresponding standard operation (that doesn't force to use an ID), so would be at the end a case in the paradoxical situation in which an operation designed to be "convenient" is not actually convenient at all due to its limitations.

In fact, this was the case of 100% users at London and Santander hackatons last months, so I think it has a lot of practical sense.

Best regards,

------
Fermín

El 25/11/2013 14:20, Tobias Jacobs escribió:
Hi Fermin,

Thanks for your efforts to improve the NGSI binding!

In case of this particular issue, as far as I remember (at is nearly 2 years ago after all) we had some lengthy discussion on whether to enforce value ids or not. For some reason (which I do not remember) we decided to enforce it, and for that reason also a PUT on an individual attribute of an entity is disallowed.

If we decide to change our minds and want to enable systems where attribute values have only one default instance, this will affect multiple places in the binding.

We can open the discussion about that again if you want; after all we have now way more practical experience with NGSI and can judge better what is important and what not.
Do you have specific reasons why you need the additional flexibility you propose?

Best
Tobias


From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Montag, 25. November 2013 12:34
To: Tobias Jacobs
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Clarification on NGSI10 binding document section 3.1.2

Dear Tobias,

The following is said in section 3.1.2 in NGSI10 binding document (PUT for ../contextEneitites/{entityID}):

"In case that a submitted ContextAttribute does not contain a value ID in the form of metadata, or if the contained value ID does not exist in the system, the respective
ContextAttributeResponse instance SHALL only consist of an error message."

If I'm understanding correctly, that writing is precluding the usage of this convenience operations in simple scenarios when "multi source" attributes are not used (i.e. ID metadata are not used), e.g. just one temperature sensor registered without ID. Is my understanding correct?

In positive case, I would suggest to make this convenience operation more flexible, using the following wording:

"In case that a submitted ContextAttribute contains a value ID in the form of metadata and the value ID does not exist in the system, the respective ContextAttributeResponse instance SHALL only consist of an error message"

What do you think?

Thanks!

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



_______________________________________________

Fiware-ngsi mailing list

Fiware-ngsi at lists.fi-ware.eu<mailto:Fiware-ngsi at lists.fi-ware.eu>

https://lists.fi-ware.eu/listinfo/fiware-ngsi

________________________________

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/20131128/5c13f28c/attachment.html>