[Fiware-ngsi] Previous email relevant on the matter

[Juanjo Hierro]

Hi,

  I believe that the email below, which I sent in December, is relevant to the discussion and may help to drive it in a fruitful and constructive manner.   I have dropped the parts that were not substantial.

  Therefore, I'm resending it as to launch the discussion.

  Cheers,

-- Juanjo


-------- Original Message --------
Subject:        Re: FW: DocumentationWSDL-NGSI10
Date:   Fri, 09 Dec 2011 08:30:45 +0100
From:   Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es>
To:     'Thierry.nagellen at orange-ftgroup.com<mailto:Thierry.nagellen at orange-ftgroup.com>' <Thierry.nagellen at orange-ftgroup.com><mailto:Thierry.nagellen at orange-ftgroup.com>, Moltchanov Boris <boris.moltchanov at telecomitalia.it><mailto:boris.moltchanov at telecomitalia.it>, Tobias Jacobs <Tobias.Jacobs at neclab.eu><mailto:Tobias.Jacobs at neclab.eu>, laurence1.dupont at orange.com<mailto:laurence1.dupont at orange.com>, Guy Sharon <GUYSH at il.ibm.com><mailto:GUYSH at il.ibm.com>, Bisztray, Denes (NSN - HU/Budapest) <denes.bisztray at nsn.com><mailto:denes.bisztray at nsn.com>, Martin Bauer <Martin.Bauer at neclab.eu><mailto:Martin.Bauer at neclab.eu>, P.Barnaghi at surrey.ac.uk<mailto:P.Barnaghi at surrey.ac.uk> <P.Barnaghi at surrey.ac.uk><mailto:P.Barnaghi at surrey.ac.uk>, RICARDO DE LAS HERAS MARTIN <rheras at tid.es><mailto:rheras at tid.es>, Haller, Stephan <stephan.haller at sap.com><mailto:stephan.haller at sap.com>, yvon.lopinto at orange.com<mailto:yvon.lopinto at orange.com>, 'Ernoe Kovacs' <Ernoe.Kovacs at neclab.eu><mailto:Ernoe.Kovacs at neclab.eu>, fano.ramparany at orange.com<mailto:fano.ramparany at orange.com> <fano.ramparany at orange.com><mailto:fano.ramparany at orange.com>, laurent.artusio at orange.com<mailto:laurent.artusio at orange.com>, jan.holler at ericsson.com<mailto:jan.holler at ericsson.com>, Licciardi Carlo Alberto <carlo.licciardi at telecomitalia.it><mailto:carlo.licciardi at telecomitalia.it>, Valla Massimo <massimo.valla at telecomitalia.it><mailto:massimo.valla at telecomitalia.it>, Farkas, Lorant (NSN - HU/Budapest) <lorant.farkas at nsn.com><mailto:lorant.farkas at nsn.com>
CC:     jhierro >> "Juan J. Hierro" <jhierro at tid.es><mailto:jhierro at tid.es>, Bohnert, Thomas Michael <thomas.michael.bohnert at sap.com><mailto:thomas.michael.bohnert at sap.com>


Hi all,

  I have been forwarded this email and, before the discussion goes into the wrong direction, let me state a number of things that I believe may be helpful to carry out a constructive discussion and find the way to move forward:

 *   OMA NGSI-9/10 specs may not be perfect at this stage and there might be some ingredients that may be useless and therefore not worth to implement.   What we want to deliver in FI-WARE is actually software that works.   However, we shouldn't see this as a problem but an opportunity: the opportunity to define a working spec that we may then fast-track for adoption in OMA either as a new version of OMA NGSI-9/10 specs or another specs that supersede them (some of us are relevant stakeholders that can really influence in the direction OMA can take)

 *   Despite the above, OMA NGSI-9/10 supports a number of the fundamental concepts that we should support in a "Thing Management layer" and that's why I rather believe it's a good idea to adopt it as the basis for the definition of the API such layer should support not just to support event query and subscription by Applications, but also registry, query and subscription-in-inventory of things (which would map the concept of entity in OMA NGSI-9/10).   This, in addition, would pave the way for a consistent model across the IoT and Data/Context Management Chapters in FI-WARE.

 *   We may not have a fully compliant implementation of the current OMA NGSI-9/10 specs at this stage but this links to the first point above.   What really matters in FI-WARE is that a) we define a consistent and single version of an API based on OMA NGSI-9/10 that we adopt in FI-WARE (note that I use "based" instead of "compliant") and b) we later fast-track its adoption in OMA.   In defining and implementing this API:
    *   We should put in practice the Agile approach and play with the fact that there will exist several FI-WARE Releases.  This means we should document the target functions we want to support in the API as Features in our backlog and then try to plan their detailed specification and implementation along the different Releases (note that the detailed specification of the signature of a given operation may be addressed as WorkItem in a Sprint and then its implementation may be addressed as a User-Story in another Sprint, both linked to Release "X" while the detailed specification and implementation of another operation may be addressed in another Release)
    *   In defining the target API, I believe we should try to go for alignment with the current NGSI-9/10 as much as possible, provided such alignment still leads to delivery of a meaningful/useful specification.   This means that if a given operation is named "B" in our asset instead of "A" and that's the only difference, we may probably go for changing it to "A" unless all agree.

 *   The implementation of OMA NGSI-9 and NGSI-10 based interfaces may not be supported by the same asset.   The implementation of both interfaces may be developed in parallel by different partners on different assets.

 *   We need to justify very well why we'll go for alternative implementations of the interfaces we will define based on OMA NGSI-9/10.   I believe there may be justifications but I want to see them and I believe our reviewers and UC projects will definitively will also claim for them.   And if we go for them, we definitively have to for all of them implementing the same set of APIs, with the same data  model.

  Best regards,

-- Juanjo



________________________________
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/20120104/f9cd19a1/attachment.html>