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.
YAML is never a great anything.