[Fiware-ngsi] NGSI last open questions

[Haller, Stephan]

I agree. For these more complicated  types of queries one should use the queryContext function and not the convenience functions.

Regards,
-Stephan

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: Montag, 2. April 2012 14:59
To: ext Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu
Subject: Re: [Fiware-ngsi] NGSI last open questions

Not allowing regular expressions in the URI is something I support as well.

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

Hi,

Fine, I think we have an agreement :). I am going to update the binding document accordingly.

One more thing (again, sorry) we have not discussed yet: Do we allow Entity ID patterns (i.e. regular expressions) in the {entityID} field? Our suggestion is 'no'.

Best
Tobias


From: Bisztray, Denes (NSN - HU/Budapest) [mailto:denes.bisztray at nsn.com]
Sent: Montag, 2. April 2012 14:43
To: Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: 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]<mailto:[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<mailto: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<mailto: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/67a6bedb/attachment.html>