search

beckn / PULSE-Specification

Adaptation of beckn protocol for online dispute resolution
Other
2 stars 9 forks source link

The JSON examples in the specification do not match the specification #24

Open rajaneeshk90 opened 5 months ago

rajaneeshk90 commented 5 months ago

Name: Pulse Specification About: The examples are incorrect labels: ODR, Example JSON, catalog

Description

The examples in the specification dont follow the specification definition. For example, the on_search catalog in this file is not as per the specification.

The message.provider should be inside the message.catalog.

Goals

Make the examples consistent with the specification.

Implementation Details

Go through the JSON examples present in /examples dir Check if they are consistent with the specification Fix all the inconsistencies found

rajaneeshk90 commented 5 months ago

https://github.com/beckn/beckn-sandbox/issues/97

tkkr6895 commented 4 months ago

Hi @rajaneeshk90, highlighting another discrepancy between the API specs and the postman collection sandbox artefact for ODR.

The init requests in the postman collections utilize the tags object to differentiate between the init requests wherein the "respondent", "consent-form" and "dispute-details" are being submitted by the seeker app. In the examples mentioned in this PULSE repo, each of these details are being collected through xinput-forms.

Please help resolve this inconsistency.

Additionally, for submitting dispute details in particular, is there no other object in the core-schema that can handle this? As of now the parameters being passed is just a large text/description and a numerical claim value, can this not be achieved without rendering a form?

rajaneeshk90 commented 4 months ago

Hi @tkkr6895

Thank you for raising these points.

The Postman collection we're discussing is specifically designed for use with the sandbox environment. The inclusion of additional tags such as "respondent", "consent-form", and "dispute-details" in the init request serves the purpose of simulating dynamic behavior within the sandbox environment. This becomes necessary due to the current absence of xinput functionality in the sandbox. It's important to note that these tags are utilized solely within the sandbox environment to differentiate between various types of init requests. However, when implementing the PULSE specification to develop an application, it's strongly recommended to adhere to the standard practice of submitting these details through the designated xinput forms.

Regarding the submission of dispute details. Currently, there isn't a dedicated object in the core schema specifically tailored for handling dispute details. While certain implementations may rely on a text field and a numerical value, it's essential not to limit ourselves to these parameters exclusively.

Different implementers may have varied requirements for capturing respondent details. Utilizing an xinput form provides flexibility to BPPs in accommodating diverse input types. This adaptability ensures that the system remains scalable and customizable to meet the unique needs of each implementation.

I trust you find this helpful.

Thanks,