OVS 3.0: SD-3427: Improve facilityTypeCode description

[HenrikHL]

SD-3427: Clarify which 3.0.2 timestamps to send to "early" adopters

[qodo-code-review]

PR Summary by Qodo

Clarify PBPL timestamp compatibility for pre-3.0.2 consumers

📝 Documentation 🕐 Less than 10 minutes

AI Description

• Clarifies API-Version requirements and legacy version handling for OVS consumers.
• Requires providers to omit PBPL timestamps for consumers below OVS 3.0.2.

High-Level Assessment

The current approach is appropriate because documenting the rule on both API-Version and facilityTypeCode makes the compatibility requirement discoverable from either contract entry point. A centralized note would reduce duplication but make the requirement easier to miss.

Files changed (1) +9 / -1

Documentation (1) +9 / -1

OVS_v3.0.3.yamlDocument legacy consumer handling for PBPL timestamps +9/-1

Document legacy consumer handling for PBPL timestamps

• Clarifies that API-Version identifies the consumer implementation and defines absent or legacy version values as 3.0.0 for compatibility checks. Specifies that providers must omit the entire Timestamp containing PBPL for consumers below version 3.0.2 rather than removing or substituting facilityTypeCode.

ovs/v3/OVS_v3.0.3.yaml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[Copilot]

🟡 Changes recommended

The new API-Version request-header wording is ambiguous versus the existing response-header definition and should be clarified to avoid implementer confusion.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

This PR updates the OVS 3.0.3 OpenAPI specification text to clarify backwards-compatibility behavior around Timestamp.facilityTypeCode=PBPL when interacting with consumers using API versions older than 3.0.2.

Changes:

• Expanded the API-Version header parameter description to include consumer-version-based compatibility rules for omitting Timestamp entries with facilityTypeCode=PBPL.
• Added an explicit backwards-compatibility note to the facilityTypeCode schema description reiterating the required omission behavior for older consumer versions.

File summaries

File	Description
ovs/v3/OVS_v3.0.3.yaml	Clarifies API-Version header semantics and PBPL/Timestamp backwards-compatibility expectations in the OVS 3.0.3 spec.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.