Question
I have a hypothetical question over the usage of terminology in the actual data payload that the consumer will ingest. Imagine I have a data service that I wrote and launched '20' years ago. In the data content there is numerical data for temperatures and times for a point in space, but there is also the text "Aerodrome".
As the service was written '20' years ago there is a strong possibility that the meaning of the word "Aerodrome" in the data payload does not exactly fit the meaning of the word "Aerodrome" as laid out according to the AIRM definition. Under what circumstances would this payload be valid - or would it be advised to re-write the payload from scratch so that the definitions are always common in both the payload and service description?
I suppose what I am asking is 'do you see more SWIM services being developed with a pre-understanding of SWIM from scratch' in favour of taking existing operational services and adding SWIM descriptions to them?
Answer - elements of answers (to be checked)
Interesting hypothetical question. Below some elements of answers (from my point of view)
- AIRM is not trying to take distance from the past and introduce a new way to name things. It’s just formalising it, and aligning to ICAO when possible. So chances are that if the word was chosen carefully in the past, it’s still the same word used in AIRM.
- Being old or new, words in a system may take distance from the words in AIRM. That’s perfectly valid. And that’s where the “AIRM trace” comes into play: you make clear how your words map to the AIRM ones, so everyone may know precisely what you mean by “Aerodrome”.
- In summary, I would not advice to rewrite payload just for the sake of being closer to AIRM. However, if you start something from scratch, it would make sense to genuinely use AIRM wording. (Note technical adaptation might however be necessary for aligning to Yellow Profile.)
Supporting Material