4 ms·

Parsing the data formats had zero contribution to the problem. They had a problem running an algorithm on the input data, and error reporting when that algorith

Parsing the data formats had zero contribution to the problem. They had a problem running an algorithm on the input data, and error reporting when that algorithm failed. Nothing about JSON would improve the situation.

rglover 3y ago
Yes, but look at the data. The algorithm was buggy because the input data is a nightmare. If the data didn't look like that, it's very unlikely the bug(s) would have ever existed.
- dundarious 3y ago
  ADEXP sounds like the universal data standard you want then. The UK just has an existing NATS that cannot understand it without transformation by this problematic algorithm. So the significant part of your suggestion might be to elide the NATS specific processing and upgrade NATS to use ADEXP directly. Using a JSON format changes nothing. Just adds a few more characters to the text representation.
- schainks 3y ago
  I have seen a bad outages caused by valid JSON whose consumer implemented something incorrectly. I agree with dundarius that "doing this in JSON" would not have changed the likelihood the bug could have manifested.
  - rglover 3y ago
    No change at all? I find that hard to believe. There's also a data design problem here, but the structure of JSON would aid in, not subtract from, that process. The question at hand is: "heavily structured data vs. a blob of text as input into a complex algorithm, which one is preferred?" Unless you're lying, you'd choose the former given the option.
    - dundarious 3y ago
      The issue is using both ADEXP and ICAO4444 waypoints, and doing so in a sloppy way. For the waypoint lists, there is no issue with structurelessness -- the fact that they're lists is pretty obvious, even in the existing formats. Adding some ["",] would not have helped the specific problem, as the relevant structure was already perfectly clear to the implementers. I am not lying when I say the bug would have been equally likely in a JSON format in this specific case.
      - schainks 3y ago
        Now I'm wigging out to the idea of how the act of overcoming the inertia of the existing system just to migrate to JSON would spawn thousands of bugs on its own — many life-threatening, surely.
    - schainks 3y ago
      These old standards ARE heavily structured data, despite what their formatting or lack of punctuation suggests.
- numpad0 3y ago
  To me and XML-ified this would look more nightmarish than the status quo... it's just brief, space separated and \n terminated ASCII. No need to overcomplicate things this simple.
- zimpenfish 3y ago
  > The algorithm was buggy because the input data is a nightmare. No, the algorithm was "buggy" because it didn't account for the entry to and exit points from the UK to have the same designation because they're supposed to be geographically distant (they were 4000Nm apart!) and the UK ain't that big.

rglover 3y ago

Yes, but look at the data. The algorithm was buggy because the input data is a nightmare. If the data didn't look like that, it's very unlikely the bug(s) would have ever existed.

dundarious 3y ago
ADEXP sounds like the universal data standard you want then. The UK just has an existing NATS that cannot understand it without transformation by this problematic algorithm. So the significant part of your suggestion might be to elide the NATS specific processing and upgrade NATS to use ADEXP directly. Using a JSON format changes nothing. Just adds a few more characters to the text representation.
schainks 3y ago
I have seen a bad outages caused by valid JSON whose consumer implemented something incorrectly. I agree with dundarius that "doing this in JSON" would not have changed the likelihood the bug could have manifested.
- rglover 3y ago
  No change at all? I find that hard to believe. There's also a data design problem here, but the structure of JSON would aid in, not subtract from, that process. The question at hand is: "heavily structured data vs. a blob of text as input into a complex algorithm, which one is preferred?" Unless you're lying, you'd choose the former given the option.
  - dundarious 3y ago
    The issue is using both ADEXP and ICAO4444 waypoints, and doing so in a sloppy way. For the waypoint lists, there is no issue with structurelessness -- the fact that they're lists is pretty obvious, even in the existing formats. Adding some ["",] would not have helped the specific problem, as the relevant structure was already perfectly clear to the implementers. I am not lying when I say the bug would have been equally likely in a JSON format in this specific case.
    - schainks 3y ago
      Now I'm wigging out to the idea of how the act of overcoming the inertia of the existing system just to migrate to JSON would spawn thousands of bugs on its own — many life-threatening, surely.
  - schainks 3y ago
    These old standards ARE heavily structured data, despite what their formatting or lack of punctuation suggests.
numpad0 3y ago
To me and XML-ified this would look more nightmarish than the status quo... it's just brief, space separated and \n terminated ASCII. No need to overcomplicate things this simple.
zimpenfish 3y ago
> The algorithm was buggy because the input data is a nightmare. No, the algorithm was "buggy" because it didn't account for the entry to and exit points from the UK to have the same designation because they're supposed to be geographically distant (they were 4000Nm apart!) and the UK ain't that big.