The JSON examples in the specification do not match the specification about pulse-specification HOT 3 OPEN

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

from pulse-specification.

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?

from pulse-specification.

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,

from pulse-specification.