[Fiware-ngsi] one further binding question

[Moltchanov Boris]

Maybe we may enforce the OMA spec in order to suggest type+entityID unique and fixing the type as mandatory.

I'm sorry for this conclusion proposed to use, as from my previous email, it would be difficult to guarantee the entityID uniqueness universally.

This is valid for overall NGSI spec that we're going to adopt at the Pub/Sub level (I mean generically within FI-WARE domain), while for IoT NGSI belonging to the WSN domain could be more restrictive and define the entityID (sensorID) as an unique identifier.

Then at the FI-WARE level we will still use the same NGSI spec where the sensor data are identified with type=wsn +  entityID=sensorB, where sensorB is unique for wsn domain, the application is using the wsn:sensorB couple. And the type field shall be mandatory on the NGSI interface level (NGSI broker installed within WSN gateway), enforcing its mandatory nature at the FI-WARE NGSI specification level.

I'm trying to do it as much universal as possible for the applications so less restrictions nevertheless taking into consideration that the sensor entityID might be unique because they univocally identify the entities within IoT world.

B

From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of laurent.artusio at orange.com
Sent: Thursday, March 29, 2012 2:36 PM
To: fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] one further binding question

Hi Tobias,

I agree with Denes. The type field being optional in NGSI spec, it can be confusing for a developer to combine id with type to guarantee uniqueness. In such case, the type field can be understood as sort of mandatory.

BR,

Laurent

De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Bisztray, Denes (NSN - HU/Budapest)
Envoyé : jeudi 29 mars 2012 14:04
À : ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Objet : Re: [Fiware-ngsi] one further binding question

Hi Tobias,

There is that "if". I would go for the variant "EntityID uniqueness is guaranteed by the ID alone."

Best,
Dénes

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu]
Sent: Thursday, March 29, 2012 1:16 PM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] one further binding question

Hi Denes,

In Table 5.5.5 in the NGSI specs it is written "If EntityId uniqueness is only guaranteed in combination with Type, then Type SHALL be present."
I interpret this as NGSI admitting to have several Entities having the same name but different type.

Such sets on Entities with the same name would be represented by the same ../contextEntities/{entityID} resource in our binding (unless we agree to do it differently).

Best
Tobias

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Donnerstag, 29. März 2012 10:09
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] one further binding question

Something completely different:
I assumed until now that the Name of the EntityId  in our system has to be unique because of the nature of the RESTful binding. Does that hold?

Best,
Dénes

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]<mailto:[mailto:fiware-ngsi-bounces at lists.fi-ware.eu]> On Behalf Of ext Tobias Jacobs
Sent: Wednesday, March 28, 2012 5:51 PM
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] one further binding question

Dear members of the NGSI list,

The binding of NGSI-10 is now as good as finished, see the current version at
https://forge.fi-ware.eu/scmrepos/svn/iot/trunk/documents/Ngsi10-RestfulBinding-Draft.docx

Unfortunately, I have identified another issue I like to discuss with you. Please let me know your opinion.

We previously agreed that a GET on an ../{EntityID} resource results in a list of all available attribute values in only one ContextElement, without attribute domains. We further agreed that a GET on ../{EntityID}/attributeDomains results in the same information, but here the response consists of one ContextElement per attribute domain.

Now here is the problem I see: The possibility to distinguish between these two kind of queries goes beyond the specification of NGSI-10. NGSI-10 only allows a query for all attributes of an entity, and how the returned information is structured is not written in the standard.

My proposal to resolve this is to disallow the GET on ../{EntityID}/attributeDomains, which would mean that this resource becomes one which does not allow any interaction. Additionally, we could leave it to the system if the attributes should be structured by domain or not, like the NGSI-10 spec does.
Martin does not agree with that, his proposal is to accept this slight extension of NGSI-10.

What speaks for Martin is (correct me if I cite you incorrectly, Martin)

-          Allowing a GET on ../{EntityID}/attributeDomains is natural, and users would expect it

-          The functionality is useful
What speaks for my approach is

-          A gap between the functionality of the binding and the functionality of NGSI-spec might cause unforeseen problems, for example when someone has already designed a system according to the NGSI-specs and now wants to put a REST interface on top.

Thanks in advance for letting us know your opinion.
Best
Tobias

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:00000000000000000000000000000003 at TI.Disclaimer]Rispetta l'ambiente. Non stampare questa mail se non è necessario.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120329/28ddc401/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120329/28ddc401/attachment.jpg>