Related to #1099, #1195, and others:
There's common perception that the JSON output of print (and maybe other reports) is complex and harder-than-necessary for humans to work with. It is a bit complex, because it tries to represent the internal data types faithfully and losslessly, as far as possible.
Chunhui Ouyang has been working on a simpler, easier-to-consume JSON schema, in chat. Here is the latest draft as of today:
[
{
"code": "",
"comment": "",
"date": "",
"date2": "",
"payee": "",
"description": "",
"status": "",
"tags": {
"key1": "value1",
"key2": "value2"
},
"postings": [
{
"account": "USD",
"amount": [
{
"commodity": "",
"cost": {
"commodity": "",
"display_value": "",
"value": ""
},
"display_value": "1000.53",
"value": "1000.52860"
}
],
"comment": "",
"tags": {
"key1": "value1",
"key2": "value2"
}
}
]
}
]The main difference from the current hledger print -O json schema is a simpler (and more lossy, because of using json's native numbers) representation of amounts.
Since print is often used for export, not just reporting, I feel the lossiness might be a problem (disrupting balanced transactions, balance assertions, etc.) But it's hard to say how much of a problem, without some testing.
Someone could add this alternate json schema to print fairly easily. (We need to keep the existing non-lossy schema also.) Call it print -O json2 or something for now. I think what it needs next is an app using it, with real world data, so that we could get some experience with it and judge its effectiveness.
Note, simple/easier to work with is the goal here. A related but different goal could be "use (or be more like) a standard schema used by others". We searched briefly and didn't find an obvious one of those. Microsoft Common Data Model and XBRL (eXtensible Business Reporting Language) were some possibilities.
Related to #1099, #1195, and others:
There's common perception that the JSON output of
print(and maybe other reports) is complex and harder-than-necessary for humans to work with. It is a bit complex, because it tries to represent the internal data types faithfully and losslessly, as far as possible.Chunhui Ouyang has been working on a simpler, easier-to-consume JSON schema, in chat. Here is the latest draft as of today:
[ { "code": "", "comment": "", "date": "", "date2": "", "payee": "", "description": "", "status": "", "tags": { "key1": "value1", "key2": "value2" }, "postings": [ { "account": "USD", "amount": [ { "commodity": "", "cost": { "commodity": "", "display_value": "", "value": "" }, "display_value": "1000.53", "value": "1000.52860" } ], "comment": "", "tags": { "key1": "value1", "key2": "value2" } } ] } ]The main difference from the current
hledger print -O jsonschema is a simpler (and more lossy, because of using json's native numbers) representation of amounts.Since print is often used for export, not just reporting, I feel the lossiness might be a problem (disrupting balanced transactions, balance assertions, etc.) But it's hard to say how much of a problem, without some testing.
Someone could add this alternate json schema to
printfairly easily. (We need to keep the existing non-lossy schema also.) Call itprint -O json2or something for now. I think what it needs next is an app using it, with real world data, so that we could get some experience with it and judge its effectiveness.Note, simple/easier to work with is the goal here. A related but different goal could be "use (or be more like) a standard schema used by others". We searched briefly and didn't find an obvious one of those. Microsoft Common Data Model and XBRL (eXtensible Business Reporting Language) were some possibilities.