[Fiware-ngsi] NGSI last open questions

[Bisztray, Denes (NSN - HU/Budapest)]

Dear Boris,

 

You just sent a mail today at 11:22 demanding the finalized NGSI spec. 

THUS I speeded up things.

 

If you think this is an Arch Board level decision then I find it pretty unfair forcing us into a hasty decision yourself and then criticizing us for the same thing. Although I wonder why did not you help us with the creation of the spec, after all you have to implement it as well. 

I welcome you to open such debate in the Arch Board if you wish.

 

BTW: Orange did vote, apparently. 

 

Best,

Dénes

 

 

From: ext Moltchanov Boris [mailto:boris.moltchanov at telecomitalia.it] 
Sent: Monday, April 02, 2012 4:34 PM
To: Bisztray, Denes (NSN - HU/Budapest); ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: RE: [Fiware-ngsi] NGSI last open questions

 

Dear All, 

 

I am sorry, we cannot assign unique ID for overall FI-WARE project on behalf of all partners and of the future of the FI. Sorry, I may not. Someone has to take this responsibility for such a decision and then design a registry for all types, domain IDs and unique IDs within FI-WARE. 

I don't see a problem with type+ID on FI-WARE higher level.

 

And who will decide, define and take the responsibility to define, assign and control the overall Future Internet name space? And when the project finished? 

 

I suggest do not limit the specification to the uniqueID and to have both possible: the uniqueID for IoT with a default IoT type or explicit type+ID for other domains, and leave it open to different types with their own IDs. 

 

I didn't see Orange, that, as an operator with mobile devices and persons and not only sensor nodes, might have probably the same TI's vision with regards to this "voting". And anyway "Boris vs. Tobias+Denes" J dispute is not at the same level of its importance and impact. This issue worth an Arch Board decision weighting all pro and cons and taking the responsibility for the consequences. And I hope this will happen, if this vision is different.

 

I understand that at this phase, in this specific NGSI related to IoT exercise it seems like a simplification, however it GREATLY impact on the interworking and interoperability therefore large scale propagation and validation of the project outcomes and of Future Internet (!) and complicates its Architecture with adding a new module for the name space allocation, name assignments and resolution. 

 

We have to be careful.

 

BR,

B

 

From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Bisztray, Denes (NSN - HU/Budapest)
Sent: Monday, April 02, 2012 2:43 PM
To: ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI last open questions

 

Hi Tobias, All.

 

1.       So Orange, NSN and NEC is for the uniqueness of EntityID alone without the type. TI (Boris) is for ID + Type.  I believe we can assume that this is decided.

 

 

2.       I would not go into such an intricate philosophical debate. I support your approach on disallowed GET for now. Maybe we can come back to this when standardizing NGSI9. Going like this is a safe approach. 

 

Best,

Dénes

 

From: ext Tobias Jacobs [mailto:Tobias.Jacobs at neclab.eu] 
Sent: Monday, April 02, 2012 2:37 PM
To: Bisztray, Denes (NSN - HU/Budapest); fiware-ngsi at lists.fi-ware.eu
Subject: RE: NGSI last open questions

 

Hi Denes,

 

1. For us it is ok to assume uniqueness of EntityID.

 

2. You mean a GET on ../{entityID}/attributeDomains means "give me a list of all attributeDomains of this entity you have information about"? This is actually rather an NGSI-9 request, because it is on the availability of context information. I would try not to mix this. Of course we can still discuss about such a convenience function in NGSI-9 binding.

Here I would still rather go for either Martin's approach (return all attribute values, grouped by domain) or my approach (do not allow the request). 

 

Best

Tobias

 

From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com] 
Sent: Montag, 2. April 2012 14:07
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: NGSI last open questions

 

Dear All,

As far as I remember we have only two open questions left with the NGSI-10 RESTful binding. 

Let me elaborate on these two:

1.      Entity ID uniqueness

As previously mentioned I vote for the sole uniquenss of the Entity ID without the Type.

My reasons are:

a)      If we allow the type+ID combo-uniqueness the whole RESTful binding goes down the drain.

b)      I don't see real problems with having a unique name. I understand that having a phone and person with name Peter would make sense, but then what would the other all the other Peters doing? They have a name clash even within a single type. 

2.      What should a GET on the /{entityId}/attributeDomains return

Tobias proposed not to return anything, Martin proposed to return all attributes ordered by domains. 

I Currently there is no way to get a list of defined attributeDomains in an entity. Thus, we need some kind of method to get that list. However, returning all attributes as well is not good here, there are several ways to get a list of attributes. I propose the following response for the GET:

returnAttributeDomainsResponse

parts:

Part name: AttributeDomainList

Part type: String[0..unbounded]

Part name: ResponseCode

Part type: StatusCode

Please respond in this questions ASAP.

Best,

Dénes

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20120402/16366f18/attachment.html>