Documenting vendor- and country-specific fields

[arjanlamersmanuchar]

At JoinData we got the request to publish country-specific fields in our documentation. Since our documentation is based on ICAR published standards, this is something that we are hesitant to do. Especially since we may have multiple sources and we would have to merge individual extensions to a single document. If a client connects directly to a service, this is not a problem: the service simply will publish its own extended version of ADE. But for a hub like JoinData, it is more tricky.

Context

ICAR ADE currently states You are free to simply add more fields to your messages than described in the standard., which is makes perfect sense.

It also states that:
"Consider if your field is potentially standardizable. If other regions or vendors may require something similar, define it in such a way that it may become part of the standard at one time."

This is currently a bit tricky: there is no way to see what other vendors or countries are doing and if you are potentially creating conflicting, ambiguous or duplicate fields.

Proposal
A proposal to solve this is to have ICAR publish known vendor- or country specific fields. That could be done by publishing e.g. an arrivals-with-extended-fields message next to the arrivals message (extending it). Vendors are then able to publish their specific fields at that message, solving any conflicts there, while at the same time keeping the standard concise. This would also allow a field to be promoted to the standard when the WG decides on that (as is hinted on the wiki as well: " By doing this, no technical changes may be required by the time a new version comes out which includes this field.").

[alamers]

Oops, published it on a different account ;)

[cookeac]

At our meeting on 2022-08-25 we agreed that these parallel extended resources would be a good method of documentation:

• They should be placed in a separate folder (e.g. /extended-fields or /proposed-extensions)
• They should use "allOf" to incorporate the standard resources
• They are only for documentation purposes - not part of the standard or incorporated in the example URL schemes
• Implementers may choose to replace the standard resources with these within their own implementations if they want to support all possible extensions.
• Proposers will still submit pull requests which the technical working group can review, which will help us suggest where these could usefully be incorporated in a future version of the standard.

@alamers and @erwinspeybroeck will test this in a use case they are working on and the technical working group will review.

[cookeac]

The current pressure for this has lessened. If anyone else needs this, they could pick up this issue and implement as suggested.