Skip to content

OVS 3.0: SD-3427: Improve facilityTypeCode description #654

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
HenrikHL merged 1 commit into from
Sep 18, 2026
Merged

OVS 3.0: SD-3427: Improve facilityTypeCode description #654

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 9 additions & 1 deletion ovs/v3/OVS_v3.0.3.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,7 +234,13 @@ paths:
- name: API-Version
in: header
description: |
From v3.0.1 and onward - every API request and response must contain the API-Version header, set to the full version of the implemented DCSA standard.
The API version implemented by the consumer.

From v3.0.1 onward, every API request and response must contain the API-Version header set to the full version of the implemented DCSA standard.

A provider responding to a consumer version lower than `3.0.2` **MUST NOT** include a `Timestamp` whose `facilityTypeCode` is `PBPL`. The entire `Timestamp` object **MUST** be omitted. The provider **MUST NOT** omit only `facilityTypeCode` or replace `PBPL` with `BRTH`, because an omitted `facilityTypeCode` has the default meaning `BRTH`.

For this compatibility rule, an absent header or the legacy value `3` **MUST** be treated as version `3.0.0`.
Comment thread
HenrikHL marked this conversation as resolved.
schema:
type: string
example: '3.0.3'
Expand Down Expand Up @@ -835,6 +841,8 @@ components:
`facilityTypeCode` has no business meaning when the containing **TransportCall** has `location.locationType` set to `WWAY`. Providers **SHOULD** omit it for such TransportCalls.

The `BRTH` default is retained for backwards compatibility. If schema-driven tooling materializes `BRTH` for a **TransportCall** with `location.locationType` set to `WWAY`, consumers **MUST** disregard the value and **MUST NOT** interpret it as vessel berthing.

**Backwards compatibility:** When the request `API-Version` identifies a consumer version lower than `3.0.2`, the provider **MUST omit the entire Timestamp** when this value is `PBPL`.
example: BRTH
required:
- eventClassifierCode
Expand Down
Loading