BKG 2.0, EBL 3.0: SD-3102, SD-2930, SD-2931, SD-2860: Link to reference page for eblPlatform, sendToPlatform and IdentifyingCodes - #636
Conversation
PR Summary by QodoEBL 3.0: Allow
AI Description
Diagram
High-Level Assessment
Files changed (3)
|
Code Review by Qodo
Context used 1.
|
There was a problem hiding this comment.
Pull request overview
This PR updates the EBL 3.0 OpenAPI specifications to allow a “Not Applicable” identifying-code provider (NA) for parties that must still provide an identifyingCodes entry even when no real identifying code exists (per SD-3102).
Changes:
- Added a new
IdentifyingCodeExtendedschema (includingNAin the documented provider list + NA-specific conditions). - Updated
Consignee.identifyingCodesandEndorsee.identifyingCodesitem schema references toIdentifyingCodeExtended. - Applied the above updates consistently across the PINT, Issuance, and main EBL v3 specs.
Reviewed changes
Copilot reviewed 3 out of 4 changed files in this pull request and generated 6 comments.
| File | Description |
|---|---|
| pint/v3/EBL_PINT_v3.0.0.yaml | Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it. |
| ebl/v3/issuance/EBL_ISS_v3.0.4.yaml | Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it. |
| ebl/v3/EBL_v3.0.4.yaml | Adds IdentifyingCodeExtended and switches Consignee/Endorsee identifyingCodes to it. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
Co-authored-by: Copilot Autofix powered by AI <[email protected]>
| - `NA` (Not Applicable) | ||
|
|
||
| **Condition:** When an identifying code is not available then `codeListProvider` MUST be `NA`. | ||
| example: W3C |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated 3 comments.
Comments suppressed due to low confidence (1)
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:511
- The
IdentifyingCode.partyCodedescription doesn’t document howpartyCodeshould be populated for the No Party placeholder, even though the schema now explicitly allowscodeListProvider='NONE'and the earlier example setspartyCodetoNONE. Adding the corresponding condition here would make the placeholder requirements self-contained and consistent.
partyCode:
type: string
description: |
Code to identify the party as provided by the `codeListProvider`
maxLength: 150
| description: | | ||
| A code and value that uniquely identifies a party. | ||
| Code-based identifier for a party. Includes the provider, code, and list name. | ||
| properties: | ||
| codeListProvider: | ||
| type: string |
| - `NONE` (To be used as part of the '**No Party**' object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`) | ||
| The eBL platform of the `Recipient Party`. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers). | ||
|
|
||
| **Condition:** When this ebl platform represents the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED` - the value MUST be `NONE`. The value `NONE` MUST be added to the allowed values from the link above. |
| - `DOCU` (DocuTrade) | ||
| - `AEOT` (AEOTrade) | ||
| - `SGTD` (SGTraDex) | ||
| The eBL platform of the party. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers). |
NA to codeListProvider for Consignee and EndorseeThere was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 7 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (3)
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:498
- In this condition,
codeListProvider='NONE'should be formatted as code (backticks) for consistency with other conditions (e.g.,codeListProvider='NA') and to avoid it being read as prose.
**Condition:** When an identifying code is used in the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`, the special value codeListProvider='NONE' should be used instead of any value from the DCSA list of party code list providers.
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:273
- The No Party example JSON is mis-indented:
partyNameis indented further than the surrounding fields, which makes the example harder to read and inconsistent with earlier versions (e.g., v3.0.3).
'partyName': 'NONE',
ebl/v3/surrender/EBL_SUR_v3.0.4.yaml:290
RecipientParty.eblPlatformdescription refers tocodeListProvider='NONE', but this field iseblPlatform. The special-case value should be documented aseblPlatform='NONE'for the No Party object; otherwise the description contradicts the example and the previous explicitNONEvalue.
This issue also appears on line 498 of the same file.
The eBL platform of the `Recipient Party`. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers).
**Condition:** When this ebl platform is used in the **No Party** object when `actionCode` is `SIGN`, `BLANK ENDORSE` or `SURRENDERED`, the special value codeListProvider='NONE' should be used instead of any value from the DCSA list of party code list providers.
|
/agentic_review |
Code Review by Qodo
Context used 1.
|
| - `DOCU` (DocuTrade) | ||
| - `AEOT` (AEOTrade) | ||
| - `SGTD` (SGTraDex) | ||
| The eBL platform of the party. Possible values are those in the latest version 1.* of the [DCSA list of eBL Platforms](https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providers). |
There was a problem hiding this comment.
1. Platform constraint weakened 🐞 Bug ≡ Correctness
Multiple eblPlatform/sendToPlatform fields now say “Possible values are …” instead of preserving the explicit “value MUST be one of …” requirement, making the normative restriction ambiguous (especially since these fields are not constrained by enum). This risks divergent interpretations across versions and implementations about whether non-registry codes are allowed.
Agent Prompt
## Issue description
Several schemas changed from an explicit normative constraint ("The value **MUST** be one of") to a looser phrasing ("Possible values are those in …"). Because these constraints are expressed only in prose (no `enum`), the new wording makes it unclear whether values outside the referenced registry are allowed.
## Issue Context
Earlier contract versions in this repo still use the explicit MUST language for these same fields, so the change introduces cross-version inconsistency and reduces conformance clarity.
## Fix Focus Areas
- ebl/v3/EBL_v3.0.4.yaml[5761-5767]
- ebl/v3/issuance/EBL_ISS_v3.0.4.yaml[624-630]
- bkg/v2/BKG_v2.0.5.yaml[4580-4586]
- pint/v3/EBL_PINT_v3.0.0.yaml[852-858]
## Suggested fix
Update the descriptions to retain normative language, e.g.:
- "The value **MUST** be one of the codes defined in the latest version 1.* of the DCSA … registry …"
Do the same for `sendToPlatform` and other touched occurrences in this PR to keep wording consistent across specs.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Change descriptions for
eblPlatformandsendToPlatform: remove list of platforms and instead link to https://reference.dcsa.org/content/standards/dcsa-code-lists/ebl-solution-providersChange description for
codeListProvider: remove list of code list providers and instead link to https://reference.dcsa.org/content/standards/dcsa-code-lists/party-code-list-providersIn some cases
codeListProvider='NA' has been added in case no code list provider is available, when that is the case, the correspondingpartyCodeMUST be set toNO VALUE`In some cases
codeListProvider='NONEhas been added in case no code list provider is applicable, when that is the case, the correspondingpartyCodeMUST be set toNONE.This PR fixes: