[Fiware-ngsi] WORRIED: No progress in FI-WARE NGSI specs ?

[Haller, Stephan]

All,

As we are implementing testing clients based on JUnit for the NGSI-10 (and possibly also -9), we will base these tests on the NGSI-Spec and the REST-binding we have defined in FI-WARE. Supporting non-standard alternatives as well would require additional efforts that are hard to justify.

I strongly advocate to stay with the standard wherever possible and only do changes/extension if absolutely needed. Staying with the standards would help in getting acceptance for what we're doing also outside the FI-WARE community.

Regards,
-Stephan



From: fiware-ngsi-bounces at lists.fi-ware.eu [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro
Sent: Dienstag, 3. Juli 2012 13:27
To: fiware-ngsi at lists.fi-ware.eu
Subject: [Fiware-ngsi] WORRIED: No progress in FI-WARE NGSI specs ?

Dear colleagues,

  I would like to share with you my concern/worries about work/progress regarding FI-WARE NGSI.

  It's been June 6th (almost one month) since I haven't seen any activity on the fiware-ngsi mailing list and this particularly worries me.  All we know that the FI-WARE NGSI API is one of the most relevant and therefore critical APIs that will be offered to UC projects.

  There are two major points for which I would like to receive your feedback:

 *   Status of FI-WARE NGSI-9 specifications:  what is the status ?  I haven't seen anything since a month ago and, actually, there is no reference to such spec on that part of the wiki where we are publishing the FI-WARE Open Specifications

 *   There is at least one aspect of the FI-WARE NGSI specs that I'm particularly worried that has not been a matter of discussion and it's rather critical IMHO: the way "restrictions" are specified and passed into requests of several operations (discoverContextAvailability, subscribeContextAvailability, queryContext, subscribeContext, updateContextSubscription).   According to the OMA specs, such restrictions should be formulated as "strings containing a XPath expression ... evaluated against ContextEntity structures" but ... is this going to be supported by TI's implementation of the Pub/Sub Broker GE ?   Shouldn't restrictions based on some language based/derived from the CQL (Context Query Language) be supported as an alternative to XPath ?

  I would rather appreciate an update regarding the first point and a response to questions formulated as second point ...

  Best regards,



-- Juanjo



-------------

Product Development and Innovation (PDI) - Telefonica Digital

website: www.tid.es<http://www.tid.es>

email: jhierro at tid.es<mailto:jhierro at tid.es>

twitter: twitter.com/JuanjoHierro



FI-WARE (European Future Internet Core Platform) Chief Architect



You can follow FI-WARE at:

  website:  http://www.fi-ware.eu

  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242

  twitter:  http://twitter.com/FIware

  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932

________________________________

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/20120703/e8f40c11/attachment.html>