Comment by Hackbraten

10 hours ago

At the cost of a slightly more complex schema, the JSON representation can be made much more readable:

    {
      "path": "/tentativeTaxNetNonRefundableCredits",
      "description": "Total tentative tax after applying non-refundable credits, but before applying refundable credits.",
      "maxOf": [
        {
          "const": {
            "value": 0,
            "currency": "Dollar"
          }
        },
        {
          "subtract": {
            "from": "/totalTentativeTax",
            "amount": "/totalNonRefundableCredits"
          }
        }
      ]
    }

YAML seems like a great middleground here between xml and json..

  • My immediate thought. Except not "vanilla" YAML, but a safer stricter subset (iirc some people published a spec about it): no implicit conversion, no norway problem, etc. If only this gained actual traction.

    The JSON in the article is a bit, let's say, heavy on the different objects and does not try to represent anything useful with most keys. All the things like `greaterOf`, `sum`, etc are much better expressed as keys than `{"children": [{"type": "greaterOf", ...}]}`.

    Basically something that feels an reads like "freeform" yaml, yet that has an actual spec.

  • I have worked with a lot of langauges over decades including YAML, and I regard it as one of the worst that I have tangled with for a number of reasons...

  • lots of haters when openspec is yaml(and json), k8s is yaml, most of go is yaml actually. sure I know it has faults, but it's really nice to type.