BKG 2.0, EBL 3.0: SD-2703: Add addressLines and align conditions

[HenrikHL]

User description

SD-2703: Add addressLines next to address object
Improve encoding
Align conditions
Added:

Consignee and Endorsee are mutually exclusive" to Consignee (it was already added on Endorsee)

SD-2848: Remove SI conditions from TD party objects

---

PR Type

Enhancement

---

Description

• Add addressLines property to multiple party and location schemas

  • Unstructured address fallback for 10+ party types and location objects
  • Support for API v3.0.3 and v2.0.4 versions

• Align and clarify conditional requirements across schemas

  • Separate conditions for v3.0.2 (or earlier) vs v3.0.3 (or later)
  • Update displayedAddress references to include addressLines

• Improve documentation clarity and consistency

  • Fix quote formatting in descriptions (e.g., "Carrier's agent at destination")
  • Update location specification descriptions to mention structured vs unstructured addresses

---

Diagram Walkthrough

flowchart LR
  A["Party & Location Schemas"] -->|"Add addressLines property"| B["Unstructured Address Support"]
  A -->|"Clarify conditions"| C["Version-specific Requirements"]
  C -->|"v3.0.2 or earlier"| D["address or identifyingCode"]
  C -->|"v3.0.3 or later"| E["address, addressLines or identifyingCode"]
  B -->|"Max 5 lines"| F["250 chars per line"]
  A -->|"Update descriptions"| G["Improved Documentation"]

Loading

File Walkthrough

	Relevant files
Enhancement	EBL_v3.0.3.yaml Add addressLines and align version-specific conditions      ebl/v3/EBL_v3.0.3.yaml Add addressLines array property (max 5 items, 250 chars each) to 11 party schemas (Shipper, ShippingAgent, Consignee, ConsigneeAgent, Endorsee, EndorseeAgent, NotifyParty, Company, ShippingInstructionsRequestor) and 3 location schemas (PlaceOfReceipt, PlaceOfDelivery, OnwardInlandRouting) Update condition descriptions to distinguish between API v3.0.2 (or earlier) and v3.0.3 (or later) requirements Clarify that displayedAddress replaces both address and addressLines in Transport Document Fix quote formatting in descriptions (e.g., "Carrier's agent at destination") Add note that Consignee and Endorsee are mutually exclusive +266/-29 EBL_ISS_v3.0.3.yaml Add addressLines and align version conditions                        ebl/v3/issuance/EBL_ISS_v3.0.3.yaml Add addressLines array property to 8 party schemas and 3 location schemas with consistent structure and constraints Update condition descriptions to separate v3.0.2 (or earlier) from v3.0.3 (or later) requirements Update location specification descriptions to clarify structured vs unstructured address options Fix quote formatting and description consistency issues +179/-20 EBL_PINT_v3.0.0.yaml Add addressLines and clarify address specifications            pint/v3/EBL_PINT_v3.0.0.yaml Add addressLines array property to 8 party schemas and 3 location schemas Update location descriptions to mention both structured and unstructured address options Update condition descriptions for v3.0.2 (or earlier) vs v3.0.3 (or later) Fix quote formatting in descriptions +174/-20 BKG_v2.0.4.yaml Add addressLines to BKG v2.0.4 schemas                                      bkg/v2/BKG_v2.0.4.yaml Add addressLines array property to 6 party schemas and 5 location schemas Update Location schema description to clarify structured vs unstructured address options Add version-specific condition for v2.0.3 (or earlier) regarding addressLines usage Update location specification descriptions across PreCarriagePickUpLocation, EmptyDepotReleaseLocation, LoadLocation, and DischargeLocation Fix quote formatting in Net Explosive Content descriptions +151/-7
Formatting	OVS_v3.0.2.yaml Fix quote formatting in address descriptions                          ovs/v3/OVS_v3.0.2.yaml Fix quote formatting and description consistency in address-related properties (street, streetNumber, floor, postCode, city, stateRegion, country) Improve description clarity for TransportCallReference +8/-8
Configuration changes	styleguide.json Styleguide configuration updates                                                  .stoplight/styleguide.json Minor configuration updates (insufficient token budget for detailed analysis) +1/-1

---

[Copilot]

Pull request overview

This PR adds support for unstructured address lines (addressLines) alongside the existing structured address object across multiple API schemas (EBL PINT, EBL Issuance, EBL, OVS, and BKG). The change provides a fallback mechanism for specifying addresses when structured address fields are unavailable, with version-specific conditions to ensure backward compatibility.

Changes:

• Added addressLines array property to location and party schemas across all affected API versions
• Updated location and party descriptions to clarify that addresses can be specified in either structured (address) or unstructured (addressLines) format
• Added backward compatibility conditions for API consumers/providers on versions 3.0.2/2.0.3 and earlier
• Fixed minor formatting issues in existing descriptions (apostrophes, spacing)

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pint/v3/EBL_PINT_v3.0.0.yaml	Adds addressLines to PlaceOfReceipt, PlaceOfDelivery, OnwardInlandRouting, and various party schemas (Shipper, DocumentParty, Consignee, Endorsee, NotifyParty); updates condition statements and fixes formatting
ovs/v3/OVS_v3.0.2.yaml	Fixes formatting in address field descriptions
ebl/v3/issuance/EBL_ISS_v3.0.3.yaml	Adds addressLines to location schemas (PlaceOfReceipt, PlaceOfDelivery, OnwardInlandRouting) and party schemas (Shipper, DocumentParty, Consignee, Endorsee, NotifyParty); fixes formatting and adds blank lines
ebl/v3/EBL_v3.0.3.yaml	Adds addressLines to party schemas (Shipper variants, DocumentParty variants, Consignee variants, Endorsee variants, NotifyParty variants, CarriersAgentAtOrigin, CarriersAgentAtDestination, ShippingInstructionsRequestor, BookingParty); updates titles, condition statements, and fixes formatting
bkg/v2/BKG_v2.0.4.yaml	Adds addressLines to party schemas (BookingParty, Shipper, Consignee, NotifyParty, CarriersAgentAtOrigin, DocumentParty) and location schemas (Location, EmptyContainerPickupLocation, EmptyContainerDropOffLocation, LoadLocation, DischargeLocation); updates condition statements and fixes formatting

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[qodo-code-review]

PR Compliance Guide 🔍

(Compliance updated until commit 1eebae1)

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #SD-2703 🟢 Add a new free-text/unstructured address field to support addresses received in unstructured form (e.g., via EDI). Keep existing required structured address fields (e.g., street, city, countryCode) as required (i.e., do not remove those requirements). ⚪ The ticket proposes adding a single free-text property on the Address object (e.g., unformatted with maxLength: 250), but the PR introduces addressLines (array, maxItems: 5, item maxLength: 250) on many party/location schemas (e.g., ShipperShipper, PartyShipper, PlaceOfReceipt, etc.); confirm this alternative is acceptable versus a field directly on the Address schema as requested.
🟡	🎫 #SD-2848 🟢 Remove the condition "Either the address or a party identifyingCode must be provided in the Shipping Instructions." from TD/ISS/PINT document party objects for: Shipper, On behalf of shipper, On behalf of consignee, Notify party, Party (general). ⚪ The diff shows removal of the SI-specific condition text in several TD/ISS/PINT party schema descriptions (e.g., On Behalf of Shipper, On Behalf of Consignee), but the full set of impacted party objects (including Shipper, NotifyParty, and Party) across TD, ISS, and PINT cannot be exhaustively confirmed from the provided hunks (and some modified files were not included, e.g., bkg/v2/BKG_v2.0.4.yaml); verify no remaining occurrences of the removed SI condition remain in TD/ISS/PINT schemas.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
⚪	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: No audit log info: This PR only changes API schema/documentation and does not show any implementation-level audit logging for critical actions, so audit trail compliance cannot be verified from the diff. Referred Code description: | The party by whom or in whose name or on whose behalf a contract of carriage of goods by sea has been concluded with a carrier, or the party by whom or in whose name, or on whose behalf, the goods are actually delivered to the carrier in relation to the contract of carriage by sea. **Condition:** If a `displayedAddress` is provided, it must be included in the `Transport Document` instead of the `address` or `addressLines`. properties: partyName: type: string pattern: ^\S(?:.*\S)?$ maxLength: 70 description: | Name of the party. example: IKEA Denmark typeOfPerson: type: string maxLength: 50 pattern: ^\S(?:.*\S)?$ description: | Can be one of the following values as per the Union Customs Code art. 5(4): - `NATURAL_PERSON` (A person that is an individual living human being) - `LEGAL_PERSON` (person (including a human being and public or private organizations) that can perform legal actions, such as own a property, sue and be sued) - `ASSOCIATION_OF_PERSONS` (Not a legal person, but recognised under Union or National law as having the capacity to perform legal acts) ... (clipped 15 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: No error handling shown: The changes are limited to OpenAPI/YAML schemas and do not include runtime code paths, so error handling and edge-case behavior cannot be assessed from this PR diff. Referred Code example: Building 123 address: $ref: '#/components/schemas/Address' addressLines: type: array maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the location. items: type: string maxLength: 250 description: | One line of an unstructured `Address`. example: "123 Example Rd" facility: Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Errors not in diff: No user-facing or internal error messages are added/changed (only schema text), so it is not possible to verify that error responses avoid leaking sensitive implementation details. Referred Code description: | The person to be notified when a shipment arrives at its destination. **Condition:** If a `displayedAddress` is provided, it must be included in the `Transport Document` instead of the `address` or `addressLines`. properties: partyName: type: string pattern: ^\S(?:.*\S)?$ maxLength: 70 description: | Name of the party. example: IKEA Denmark typeOfPerson: type: string maxLength: 50 pattern: ^\S(?:.*\S)?$ description: | Can be one of the following values as per the Union Customs Code art. 5(4): - `NATURAL_PERSON` (A person that is an individual living human being) - `LEGAL_PERSON` (person (including a human being and public or private organizations) that can perform legal actions, such as own a property, sue and be sued) - `ASSOCIATION_OF_PERSONS` (Not a legal person, but recognised under Union or National law as having the capacity to perform legal acts) ... (clipped 69 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Logging not present: The PR modifies API specifications only and contains no logging statements or logging configuration, so secure logging practices (including PII redaction) cannot be verified from the diff. Referred Code title: Party description: | Refers to a company or a legal entity. properties: partyName: type: string pattern: ^\S(?:.*\S)?$ maxLength: 70 description: | Name of the party. example: Asseco Denmark address: $ref: '#/components/schemas/PartyAddress' addressLines: type: array maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. items: type: string maxLength: 250 ... (clipped 64 lines) Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Validation enforcement unknown: While the schema adds constraints (e.g., addressLines max items/length), the diff does not show whether server-side enforcement, sanitization, and authorization controls exist for incoming data. Referred Code example: 'NATURAL_PERSON' address: $ref: '#/components/schemas/PartyAddress' addressLines: type: array maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. items: type: string maxLength: 250 description: | One line of an unstructured `Address`. example: "123 Example Rd" displayedAddress: Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

---

Previous compliance checks

Compliance check up to commit 73b117c

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #SD-2703 🟢 Keep existing required structured address fields (e.g., StreetName, City, CountryCode) as required (cannot be removed). 🔴 Add a new freetext field to the Address object to capture unstructured addresses (suggested name unformatted or similar) with maxLength 250. ⚪ Consider an alternative approach: add a freetext/unstructured address field at DocumentParty root level (e.g., freetextAddress) if acceptable.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Use reusable AddressLines component Refactor the repeated addressLines definition into a reusable schema component and use $ref to improve maintainability. ebl/v3/EBL_v3.0.3.yaml [4798-4808] addressLines: - type: array - maxItems: 5 - description: | - Unstructured address lines, used as a fallback when structured address fields are unavailable. - items: - type: string - maxLength: 250 - description: | - One line of an unstructured `Address`. - example: "123 Example Rd" + $ref: '#/components/schemas/AddressLines' Apply / Chat Suggestion importance[1-10]: 7 __ Why: This is a valuable suggestion for improving the maintainability and consistency of the OpenAPI specification by abstracting the repeated addressLines definition into a reusable component.	Medium
	Enforce non-empty addressLines Add minItems: 1 to the addressLines array property to ensure it contains at least one address line if present. ebl/v3/EBL_v3.0.3.yaml [4614-4616] addressLines: type: array + minItems: 1 maxItems: 5 Apply / Chat Suggestion importance[1-10]: 6 __ Why: This suggestion correctly points out that an empty addressLines array is not useful and proposes adding minItems: 1 to enforce that the array contains at least one element if provided, improving data integrity.	Low
	✅ Clarify backward compatibility condition for addressLines Suggestion Impact: The commit updated/remodeled multiple schema descriptions and conditions around `addressLines`, removing the previous ambiguous v3.0.2 wording and adding clearer backward-compatibility language stating that when interacting with v3.0.2-or-earlier implementations, a v3.0.3+ sender MUST NOT use `addressLines` as the only identifying property (and that earlier recipients MAY ignore it). This addresses the intent of clarifying backward compatibility, though not exactly with the suggested one-line replacement. code diff: maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. - - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. items: type: string maxLength: 250 @@ -4680,15 +4676,109 @@ required: - partyName + ShipperShipper: + type: object + title: Shipper (Shipper provided) + description: | + The party by whom or in whose name or on whose behalf a contract of carriage of goods by sea has been concluded with a carrier, or the party by whom or in whose name, or on whose behalf, the goods are actually delivered to the carrier in relation to the contract of carriage by sea. + + **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`. If a `displayedAddress` is provided, it must be included in the `Transport Document` instead of the `address`. + + **Condition:** Providers **and** consumers on API v3.0.3 (or later): Either the `address`, `addressLines` or a party `identifyingCode` must be provided in the `Shipping Instructions`. If a `displayedAddress` is provided, it must be included in the `Transport Document` instead of the `address` or `addressLines`. + properties: + partyName: + type: string + pattern: ^\S(?:.*\S)?$ + maxLength: 70 + description: | + Name of the party. + example: IKEA Denmark + typeOfPerson: + type: string + maxLength: 50 + pattern: ^\S(?:.*\S)?$ + description: | + Can be one of the following values as per the Union Customs Code art. 5(4): + - `NATURAL_PERSON` (A person that is an individual living human being) + - `LEGAL_PERSON` (person (including a human being and public or private organizations) that can perform legal actions, such as own a property, sue and be sued) + - `ASSOCIATION_OF_PERSONS` (Not a legal person, but recognised under Union or National law as having the capacity to perform legal acts) + example: 'NATURAL_PERSON' + address: + $ref: '#/components/schemas/PartyAddress' + addressLines: + type: array + maxItems: 5 + description: | + Unstructured address lines, used as a fallback when structured address fields are unavailable. + + **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. + items: + type: string + maxLength: 250 + description: | + One line of an unstructured `Address`. + example: "123 Example Rd" + displayedAddress: + type: array + maxItems: 6 + description: | + The address of the party to be displayed on the `Transport Document`. The displayed address may be used to match the address provided in the `Letter of Credit`. + + **Conditions:** If provided: + - the displayed address must be included in the `Transport Document`. + - for physical BL (`isElectronic=false`), it is only allowed to provide max 2 lines of 35 characters. **Note:** Some carriers may choose to allow more lines, please consult the carrier's API documentation to check if this is the case. + - for electronic BL (`isElectronic=true`), the limit is 6 lines of 35 characters + - the order of the items in this array **MUST** be preserved as by the provider of the API. + items: + type: string + maxLength: 35 + description: | + A single address line + example: Strawinskylaan 4117 + identifyingCodes: + type: array + description: | + **Condition:** Either the `address` or a party `identifyingCode` must be provided. + items: + $ref: '#/components/schemas/IdentifyingCode' + taxLegalReferences: + description: | + A list of `Tax References` for a `Party` + type: array + items: + $ref: '#/components/schemas/TaxLegalReference' + partyContactDetails: + type: array + description: | + A list of contact details + items: + $ref: '#/components/schemas/PartyContactDetail' + reference: + type: string + pattern: ^\S(?:.*\S)?$ + maxLength: 35 + description: | + A reference linked to the `Shipper`. + example: HHL007 + purchaseOrderReferences: + type: array + description: | + A list of `Purchase Order Reference`s linked to the `Shipper`. + items: + type: string + pattern: ^\S(?:.*\S)?$ + maxLength: 35 + description: | + A purchase order reference linked to the `Shipper`. + example: HHL007 + required: + - partyName + OnBehalfOfShipper: type: object title: On Behalf of Shipper description: | The party allowed to act on behalf of the shipper for documentation purposes. - - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`. - - **Condition:** Providers **and** consumers on API v3.0.3 (or later): Either the `address`, `addressLines` or a party `identifyingCode` must be provided in the `Shipping Instructions`. properties: partyName: type: string @@ -4704,8 +4794,47 @@ maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. - - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. + items: + type: string + maxLength: 250 + description: | + One line of an unstructured `Address`. + example: "123 Example Rd" + identifyingCodes: + type: array + description: | + **Condition:** Either the `address` or a party `identifyingCode` must be provided. + items: + $ref: '#/components/schemas/IdentifyingCode' + required: + - partyName + + OnBehalfOfShipperShipper: + type: object + title: On Behalf of Shipper (Shipper provided) + description: | + The party allowed to act on behalf of the shipper for documentation purposes. + + **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`. + + **Condition:** Providers **and** consumers on API v3.0.3 (or later): Either the `address`, `addressLines` or a party `identifyingCode` must be provided in the `Shipping Instructions`. + properties: + partyName: + type: string + pattern: ^\S(?:.*\S)?$ + maxLength: 70 + description: | + Name of the party. + example: IKEA Denmark + address: + $ref: '#/components/schemas/PartyAddress' + addressLines: + type: array + maxItems: 5 + description: | + Unstructured address lines, used as a fallback when structured address fields are unavailable. + + **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. items: type: string maxLength: 250 @@ -4867,10 +4996,6 @@ title: On Behalf of Consignee description: | The party allowed to act on behalf of the consignee for documentation purposes. - - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`. - - **Condition:** Providers **and** consumers on API v3.0.3 (or later): Either the `address`, `addressLines` or a party `identifyingCode` must be provided in the `Shipping Instructions`. properties: partyName: type: string @@ -4886,8 +5011,46 @@ maxItems: 5 description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. - - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. + items: + type: string + maxLength: 250 + description: | + One line of an unstructured `Address`. + example: "123 Example Rd" + identifyingCodes: + type: array + minItems: 1 + items: + $ref: '#/components/schemas/IdentifyingCode' + required: + - partyName + + OnBehalfOfConsigneeShipper: + type: object + title: On Behalf of Consignee (Shipper provided) + description: | + The party allowed to act on behalf of the consignee for documentation purposes. + + **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): Either the `address` or a party `identifyingCode` must be provided in the `Shipping Instructions`. + + **Condition:** Providers **and** consumers on API v3.0.3 (or later): Either the `address`, `addressLines` or a party `identifyingCode` must be provided in the `Shipping Instructions`. + properties: + partyName: + type: string + pattern: ^\S(?:.*\S)?$ + maxLength: 70 + description: | + Name of the party. + example: IKEA Denmark + address: + $ref: '#/components/schemas/PartyAddress' + addressLines: + type: array + maxItems: 5 + description: | + Unstructured address lines, used as a fallback when structured address fields are unavailable. + + **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. items: type: string maxLength: 250 @@ -4939,7 +5102,7 @@ description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. + **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. items: type: string maxLength: 250 @@ -5142,7 +5305,7 @@ description: | Unstructured address lines, used as a fallback when structured address fields are unavailable. - **Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. + **Condition:** When communicating with providers **or** consumers implementing API **v3.0.2 or earlier**, a sender implementing API **v3.0.3 or later MUST NOT** use `addressLines` as the only property to identify the party. Recipients implementing earlier versions **MAY ignore** this property. items: Clarify the backward compatibility condition for addressLines to state it must not be used in API v3.0.2 or earlier, as it is a new feature in v3.0.3. ebl/v3/EBL_v3.0.3.yaml [4620] -**Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` cannot be used as the only property to identify the party. +**Condition:** Providers **or** consumers on API v3.0.2 (or earlier): `addressLines` must not be used. [Suggestion processed] Suggestion importance[1-10]: 5 __ Why: The suggestion correctly identifies a confusing and likely incorrect condition for backward compatibility and proposes a clearer, more accurate description, improving the specification's correctness.	Low
Possible issue	Prevent empty strings in address lines Add minLength: 1 to the items of the addressLines array to prevent individual address lines from being empty strings. ebl/v3/EBL_v3.0.3.yaml [4621-4626] items: type: string maxLength: 250 + minLength: 1 description: | One line of an unstructured `Address`. example: "123 Example Rd" Apply / Chat Suggestion importance[1-10]: 6 __ Why: This is a good suggestion that improves the data validation of the API by ensuring that address lines cannot be empty strings, which would be meaningless data.	Low
Update

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 9 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.