[Fiware-ngsi] one further binding question

[thierry.nagellen at orange.com]

Hi All,

 

As I understand the point, because we are doing an implementation of NGSI-10, we try to solve some issues which are maybe not integrated within the standard today. In this case we could submit a proposal to OMA to modifiy a bit the standard to be sure that anybody can comment this potential improvement.

 

The main risk is that someone try to use FI-Ware NGSI-10, and this will be a very good point, but with another implementation of NGSI-10 not fully compliant with our implementation. 3 potential issues:

1.       We use FIWare NGSI 10 with several GEs and this is the interesting part for the 3rd party => He should modifiy a bit its implementation

2.       3rd party implementation is well-known by a developers community =>> we should modify our implementation

3.       We are working together to have a developers community to use NGSI-10 => we will work together to have a common implementation

 

I do not think that we can find today someone with an NGSI-10 implementation with a strong developers community so the risk is very low.

 

My conclusion: go ahead with FIWare NGSI-10 implementation, when it is running propose the improvement to OMA NGSI WG and demonstrate that FI-Ware is pushing to adopt standards and implement them.

 

BR

 

Thierry

 

De : fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Tobias Jacobs
Envoyé : mercredi 28 mars 2012 17:51
À : fiware-ngsi at lists.fi-ware.eu
Objet : [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

 

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