Dear Thierry,
Yes, we have processes for validating documents, software, etc. but, as far as I understand, they apply only to official deliverables to EC. In this case, we are talking about something very different: a .doc file living in a public SVN.
Regarding validation, considering the current case for the issue discussed in this thread: each GEi owner involved has validated agreeing in that the change is ok in a matter of days.
Best regards,
------
Fermín
El 12/12/2013 13:07, thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com> escribió:
Hi Fermin
If we publish document for everybody, we will publish again only when we are sure that changes are validated by all GEis owners impacted by some changes, and that the changes are correctly implemented.
Telefonica put in place some processes to validate documentation, software deliveries, catalogue publications, so we will follow some rules to publish documents with the relevant quality and not putting us in any trouble.
BR
Thierry
De : Fermín Galán Márquez [mailto:fermin at tid.es]
Envoyé : jeudi 12 décembre 2013 12:56
À : NAGELLEN Thierry IMT/OLPS
Cc : Rolando Sergio (Guest); Tobias Jacobs; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : Re: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Dear Therry,
"Providing a new version each month is too much"
Why is too much? Maybe I'm missign someghing but is a matter of editing the particular section in the .doc and commit to SVN.
Best regards,
------
Fermín
El 12/12/2013 11:56, thierry.nagellen at orange.com<mailto:thierry.nagellen at orange.com> escribió:
Hi all
Just a point to clarify: we want to publish for 3rd parties a frozen version, not to stop the work between partners after this frozen version. Providing a new version each month is too much but for sure we will publish a new one in April (currently official last month of the project).
So keep the last actions for January internal sprint and we will release the binding in April 2014.
BR
Thierry
De : fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] De la part de Rolando Sergio (Guest)
Envoyé : jeudi 12 décembre 2013 11:49
À : Fermín Galán Márquez; Tobias Jacobs
Cc : fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Objet : Re: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Hi all,
Since the release date is tomorrow (I have already closed "my" TI PubSub CB), I think it would be better not to include this modification right now, it could be OK starting from January sprint.
Best regards,
Sergio
________________________________
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: giovedì 12 dicembre 2013 11.39
To: Tobias Jacobs; Rolando Sergio (Guest)
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Dear Tobias,
It depends when will be that "next release"... we wouldn't like to defer this too much. In this sense, if this change is implemented in January sprint (we should work in "Agile mode", thus including modification to the spec from month to month, if needed), is ok with us not including it in the bunch to be released tomorrow.
BTW, there are other modifications that we plan to suggest to include. But let's go step by step.
Best regards,
------
Fermín
El 12/12/2013 11:32, Tobias Jacobs escribió:
Dear all,
Are we sure that we want to unify updateContextElementRequest and appendContextElementRequest in this release?
It makes technically sense, but it would make the current implementations of several partners suddenly incompatible with the public binding shortly before the review.
The other improvements that were suggested are backwards-compatible, but this one is not.
Any opinions?
Best regards
Tobias
From: Fermín Galán Márquez [mailto:fermin at tid.es]
Sent: Dienstag, 10. Dezember 2013 15:47
To: Tobias Jacobs; Rolando Sergio (Guest)
Cc: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Dear Tobias, Sergio,
Using updateContextElementRequest as unique name is also fine with us (TID).
Best regards,
------
Fermín
El 10/12/2013 14:17, Tobias Jacobs escribió:
Fine with me; and backwards compatibility is a good point!
- Tobias
From: Rolando Sergio (Guest) [mailto:sergio.rolando at guest.telecomitalia.it]
Sent: Dienstag, 10. Dezember 2013 14:14
To: Tobias Jacobs; Fermín Galán Márquez; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: RE: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Hi Tobias, hi Fermin,
I'd suggest using the unique name "updateContextElementRequest" improving backward compatibility, since also other words would not be better ("modify..." means a sort of "update", and it does not seem to suit "append" operations, or at least... not better than "update" itself).
Best regards,
Sergio
________________________________
From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Tobias Jacobs
Sent: martedì 10 dicembre 2013 13.49
To: Fermín Galán Márquez; fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: Re: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Hi Fermin,
Yes, that makes sense to me.
Best
Tobias
From: fiware-ngsi-bounces at lists.fi-ware.eu<mailto:fiware-ngsi-bounces at lists.fi-ware.eu> [mailto:fiware-ngsi-bounces at lists.fi-ware.eu] On Behalf Of Fermín Galán Márquez
Sent: Montag, 9. Dezember 2013 12:23
To: fiware-ngsi at lists.fi-ware.eu<mailto:fiware-ngsi at lists.fi-ware.eu>
Subject: [Fiware-ngsi] NGSI10 binding sections 3.1.2.1 and 3.1.3.1: identical structs
Hi,
We have found that the data structs described in NGSI10 binding document sections 3.1.2.1 and 3.1.3.1 ( updateContextElementRequest and appendContextElementRequest) are exactly equal. Thus, we suggest to have only one (probably with a different and "neutral" name, such modifyContextElementResponse).
What do you think?
Best regards,
------
Fermín
________________________________
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
________________________________
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
________________________________
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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
________________________________
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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
________________________________
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/20131212/08a0386c/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy