Dear Fermin, thanks for your reply. I have gone through the full specification of the Orion NGSI-v1 using this link: · http://fiware-orion.readthedocs.io/en/latest/user/walkthrough_apiv1/#ngsi10-standard-operations I have collected all the questions and doubts in the attached document while comparing the Orion NGSI-v1 to the original OMA NGSI. It will help us a lot to have those questions answered in order to have a first full JSON schema which should work with Orion. Once we have such schema, I think that your idea to test against the in Orion Context Broker test base is the way to go. Thank you very much for your collaboration. Best Regards Flavio From: Fermín Galán Márquez [mailto:fermin.galanmarquez at telefonica.com] Sent: 21 December 2016 15:34 To: Ernoe Kovacs; fiware-ngsi at lists.fiware.org Cc: Flavio Cirillo; Martin Bauer Subject: Re: JSON Schema Dear Enroe, Flavio, I agree in that formalizing a JSON Schema for the NGSI API would be definitively a good idea to ease integrations, along with side advantages (e.g. code stub generation based on JSON Schema). Unfortunately, it is not possible for the Orion team to change ourselves the schema your are providing at the present moment. We lack familiarity with JSON Schema syntax (and lack the time right now to get familiar with it :). In the meanwhile, let me try to answer your questions: --------------------------- · UpdateContext: o the isPattern field of the contextElment is mandatory like in the OMA NGSI? Not clear in the text It is not mandatory. From an user perspective, most of the time your are creating/updating single entities thus including "isPattern": "false" all the time would be cumbersome. As a side-node, Orion doesn't support "isPattern": "true" for updateContext operations. However, this is probably going to change in the future (see https://github.com/telefonicaid/fiware-orion/issues/1503) so the schema should allow also "isPattern": "true". o the type field of the contextElement is mandatory differently from the OMA NGSI? Not clear in the text It is not mandatory. In some use cases the type could be a secondary piece of information not actually needed (and, in that way, an overhead for use cases). Side-node: however, for internal consistency, it is good to establish that each entity/attribute/metadata must have a type (see "Field syntax restrictions" section at [1]). In NGSIv2 we support the creations of entities/attributes/metadata without type (to ease use cases, as described in the paragraph above) but in this case default typing is applied (see "Partial Representations" section at [1]) · UpdateContextType: o Found two more UpdateActionType like APPEND_STRICT and REPLACE. These two additional action types (not present in the standard OMA NGSI Specification) were explained through the whole tutorial text and not easy to get on a first glance like it would be in a table. You are right: APPEND_STRICT and REPLACE can be used also as actionTypes. I'm afraid documentation is not very good describing them at the present moment but we take note of the feedback (see https://github.com/telefonicaid/fiware-orion/issues/2783) and try to impreve it soon. o Are there any other UpdateActionType? Not at the present moment (and it seems improbable new ones are going to be added). · ContextElement o Is DomainMetadataList field suppressed? Correct. It hasn't ever implemented in CB (even in the old XML days) and we haven't got any feedback from developers in the last 4 years requiring such feature. o Is AttributeDomainName suppressed? Correct. Same reason than DomainMetadataList. --------------------------- Once the JSON Schema gets finished, I'd suggest to do a "stress test" with all the NGSIv1 JSON payloads (requests and responses) in Orion Context Broker test base (https://github.com/telefonicaid/fiware-orion/tree/master/test/functionalTest/cases). We have around 900 test cases (each one involing N JSON requests/responses) and although not all them are NGSIv1-bassed (many of them are NGSIv2-based) they could be a good way of cross-validating JSON Schema vs. real Orion usage. To ease the task, some script would be needed to extract JSON fragments from .test files so these fragments can be used by the JSON Schema validation tool. Best regards, ------ Fermín [1] http://telefonicaid.github.io/fiware-orion/api/v2/stable/ El 13/12/2016 a las 18:34, Ernoe Kovacs escribió: Hi all, Please find below the mail from Flavio drafted befor today’s meeting / agreement. But it gives some background of our thinking… Also find the schema files attached. - Ernoe Dear FIWARE partners, here at NEC, we are trying to create a JSON Schema for the JSON NGSI (version 1) specification. The motivation for this is that till now the only agreed formalization of a NGSI serialization was the XML for which we had an agreed XML schema. Thanks to that, we had a better integration between the IoT chapter components. Since then several IoT Chapter components have implemented also the JSON serialization of NGSI because it has been stated that FIWARE users would generally prefer to use JSON. The problem of this was that we have never agreed on a common JSON serialization and the result is, for example, that for the IoT Broker we have a JSON serialization pretty much close to the XML serialization, keeping the same data structure as defined in the OMA NGSI standard, and a JSON serialization made for the Orion Context Broker which slightly deviates from the original OMA NGSI standard specification. The JSON schema will help us to understand in a more formal way where the two serializations differs. What we have done first is to create the JSON schema for our NGSI serialization (attached to the mail an alpha version) and then modifying it according to the Orion version by reading from the Orion documentation (http://fiware-orion.readthedocs.io/en/latest/user/walkthrough_apiv1/#context-management-using-ngsi10). We have found very hard to follow this approach because the documentation there is very valuable from a point of view of a developer, since it is very much similar to a tutorial, but it is lacking of formality which is very useful (if not even necessary) in order to ease the task of spotting the differences with the original OMA NGSI Specification. Here some example of difficulties found so far: · UpdateContext: o the isPattern field of the contextElment is mandatory like in the OMA NGSI? Not clear in the text o the type field of the contextElement is mandatory differently from the OMA NGSI? Not clear in the text · UpdateContextType: o Found two more UpdateActionType like APPEND_STRICT and REPLACE. These two additional action types (not present in the standard OMA NGSI Specification) were explained through the whole tutorial text and not easy to get on a first glance like it would be in a table. o Are there any other UpdateActionType? · ContextElement o Is DomainMetadataList field suppressed? o Is AttributeDomainName suppressed? We are attaching also another json schema, which is the same schema we had for the NEC version with already some data structures changed accordingly to what we have inferred from the Orion documentation (only the UpdateContextRequest and connected data structures like ContextElement). It would be very useful if the Orion people will help us on finishing this document or, even better and quicker, change themselves the json schema we are providing within this mail in order to have formal specification and an easy way to make a “diff” of the two schemas. This will ease a lot the integration of the IoT Chapter components. Thank you in advance Best Regards Flavio ______________________________________________________________________________________ Dr. Ernö Kovacs エルノー・コヴァーチェ NEC Europe Ltd. NEC Laboratories Europe Senior Manager Cloud Service and Smart Things Kurfürsten-Anlage 36 | D-69115 Heidelberg E-Mail: ernoe.kovacs at neclab.eu<mailto:ernoe.kovacs at neclab.eu> Tel. +49 6221 4342 – 131 | Fax. +49 6221 4342 – 115 Mobile: +49 (163) 2086046 NEC Europe Limited | Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB | Registered in England 2832014 ______________________________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20170120/aa1ef54d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: NGSI-v1-TID-questions.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 20754 bytes Desc: NGSI-v1-TID-questions.docx URL: <https://lists.fiware.org/private/fiware-ngsi/attachments/20170120/aa1ef54d/attachment-0001.docx>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy