beckn / DSEP-Specification

Open Interoperable Specifications for Skilling and Education. An adaptation of Beckn Protocol.
Other
18 stars 22 forks source link

Hotfix: dsep v0.7.0 spec #171

Closed rajaneeshk90 closed 3 months ago

rajaneeshk90 commented 4 months ago

Issue:

Summary: The DSEP specification defined in the /api folder(link to the DSEP specification definition) references the Beckn core protocol specification version 1.1.0, but discrepancies exist in their adherence to the referenced core spec.

The discrepancies are listed in this linked GitHub issue: https://github.com/beckn/DSEP-Specification/issues/164

Changes Made:

  1. The context.city and context.country encapsulated inside a context.location object.
  2. The deviations from the DSEP specification in the examples used in DSEP specification(dsep-v0.7.yaml) were corrected.
  3. Unused components defined in specification yaml(dsep-v0.7.yaml), for example, Policy, StructuredAddress, FullAddress, FeedbackUrl, FeedbackFormElement, FeedbackForm & Feedback are removed.
  4. rating & on_rating APIs are fixed to make them follow the core-v1.1.0 specification.
nirmalnr commented 4 months ago

This still has the old version of xInput. Can we add the new version of this here in DSEP spec? Current v0.7.0 in the repo has this new version which has already been started to be used by ONEST network participants.

    XInput:
      description: 'Contains any additional or extended inputs required to confirm an order. This is typically a Form Input. Sometimes, selection of catalog elements is not enough for the BPP to confirm an order. For example, to confirm a flight ticket, the airline requires details of the passengers along with information on baggage, identity, in addition to the class of ticket. Similarly, a logistics company may require details on the nature of shipment in order to confirm the shipping. A recruiting firm may require additional details on the applicant in order to confirm a job application. For all such purposes, the BPP can choose to send this object attached to any object in the catalog that is required to be sent while placing the order. This object can typically be sent at an item level or at the order level. The item level XInput will override the Order level XInput as it indicates a special requirement of information for that particular item. Hence the BAP must render a separate form for the Item and another form at the Order level before confirmation.'
      type: object
      properties:
        required:
          description: Indicates whether the form data is mandatorily required by the BPP to confirm the order.
          type: boolean
        head:
          description: Head section of the form
          type: object
          properties:
            descriptor:
              $ref: '#/components/schemas/Descriptor'
            index:
              type: object
              properties:
                min: 
                  type: integer
                cur: 
                  type: integer
                max: 
                  type: integer
            headings: 
              type: array
              items:  
                type: string           
        form:
          $ref: '#/components/schemas/Form'
    Form:
      description: Describes a form
      type: object
      properties:
        url:
          description: ‘The URL from where the form can be fetched. The content fetched from the url must be processed as per the mime_type specified in this object. Once fetched, the rendering platform can choosed to render the form as-is as an embeddable element; or process it further to blend with the theme of the application. In case the interface is non-visual, the the render can process the form data and reproduce it as per the standard specified in the form.’
          type: string
          format: uri
        data:
          description: The form submission data
          type: object
          additionalProperties:
            type: string
        mime_type:
          description: This field indicates the nature and format of the form received by querying the url. MIME types are defined and standardized in IETF’s RFC 6838.
          type: string
          enum:
            - text/html
            - application/xml
        resubmit: 
          type: boolean
        submission_id:
          type: string
          format: uuid
        auth: 
          type: object
          properties: 
            descriptor:
              $ref: '#/components/schemas/Descriptor'
            value: 
              type: string
emmayank commented 4 months ago

Hey @rajaneeshk90 , Please find my comments on the pull request below :

  1. The examples that are defined in the YAML File (deep-v0.7.yaml) are not as per the core-v1.1 specification. Refer Line no 33. here the example of context is not aligned with the context specification.

  2. Policy, StructuredAddress, FullAddress, FeedbackUrl, FeedbackFormElement, FeedbackForm & Feedback schema is available in dsep-v0.7.yaml, but it is not available in core-v1.1.yaml.

  3. Rating & on_rating specs is not as per core-v1.1.yaml

  4. Please make the required changes in dsep-v0.6.0.yaml and dsep.yaml file as well.

I was hoping you could find the complete difference in the given comparison link (click here). Please make the required change and update the pull request.

Thanks @emmayank

rajaneeshk90 commented 3 months ago

Hi @emmayank

Thanks for taking the time out to review the change. I have made the suggested changes, please have a look.

Thanks, Rajaneesh

ravi-prakash-v commented 3 months ago

I see dsep-v0.6.0, dsep-v0.7.0, and dsep.yaml in the docs folder. Which one is the source of truth? Also, is the core submodule pointing to v1.1 of Core? Because in the Readme, I see only 1.0.0 in the version history.

emmayank commented 3 months ago

Hi @ravi-prakash-v , Thanks for the review. Please find explanation of your queries :

  1. Earlier we only had dsep.yaml , then we released some fixes and named it dsep-v0.6.0, and then later some more fixes were released which was versioned as dsep-v0.7.0. Since few NPs were still using the older version, we kept all of these versions in the same branch. Right now the latest version is dsep-v0.7.0.
  2. Yes, the core submodule points to v1.1 of Core. but in the core-protocol repository, the readme was not updated for that particular instance, where the tag was created.

Thanks @emmayank

ravi-prakash-v commented 3 months ago

Let's remove all the older versions and maintain only one dsep.yaml

emmayank commented 3 months ago

Ok, will remove all older version and rename dsep-v0.7.0.yaml as dsep.yaml

emmayank commented 3 months ago

Hi @ravi-prakash-v , Suggested changes are pushed

emmayank commented 3 months ago

Hi @ravi-prakash-v ,

Here is the link to visualize the changes made in DSEP.yaml file. https://www.textcompare.org/yaml/?id=65f29fec2e496ff11eed1f4c