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

[Tobias Jacobs]

From: Tobias Jacobs
Sent: Montag, 2. Dezember 2013 14:47
To: 'Fermín Galán Márquez'
Subject: RE: [Fiware-ngsi] Clarification on NGSI10 binding document section 3.1.2

Hi Fermin,

I think leaving it open would be the most consequent, as also the abstract interface spec does not say anything about it. For the IoT Broker this issue is also not really relevant.

We should however try to reflect the change consequently in the whole binding document, meaning that also PUT operations on resources representing individual attributes of entities become allowed now. Maybe there are even more places where this has an effect on, but I did not have the time to check up to now.

Best
Tobias

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

Dear Tobias,

We don't think mixing both cases (attributes with the same name, some with ID and one without ID) would be a significant use case. I mean, the user will  be using either one of the following case for each attribute:

  *   One attribute without ID, e.g. (nameA, typeA)
  *   Several attributes with same name and type, each with its own ID: (nameA, typeA, id1), (nameA, typeA, id2), (nameA, typeA, id3), etc.

Thus, a NGSI server implementation could enforce that a situation mixing both cases doesn't happen. In particular:

  *   At entity creation time, ensure that the client is not using at the same time (nameA, typeA) and (nameA, typeA, id1)
  *   At updateContext APPEND time, ensure that if there is an entity using (nameA, typeA) then (nameA, typeA, id1) can not be appended, or viceversa.

However, the option of leaving the exact semantics of the operation open is also fine with us. We can see this as an "implementation dependent behavior". The fact that we don't see mixing cases as a significant use case in Orion Context Broker doesn't avoid that it could be interesting for other NGSI servers implementation.

However, I think this discussion is orthogonal to the change in the wording of the spec I suggest in the my first email. Whatever decision we take, we shouldn't avoid users to use the "PUT ../contextEnitites/{entityID}" operation in simple cases when they are not using ID metadata (ID metadata is not mandatory according to NGSI9/10 base spec from OMA) and our documents should reflect that.

What do you think?

Best regards,

------
Fermín
El 28/11/2013 13:12, Tobias Jacobs escribió:
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> [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<mailto: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

________________________________

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/20131202/1688f651/attachment.html>