6 ms·

Your suggestion requires a fixed-depth hierarchy (such as three levels in your example), and then it requires a lot of redundancy. Here, I want to eliminate the

Your suggestion requires a fixed-depth hierarchy (such as three levels in your example), and then it requires a lot of redundancy. Here, I want to eliminate the redundancy not primarily for performance reasons, but to make it easier to edit the data by hand, for example to cut-and-paste some lines to move them around within the tree without having to change the leading values. To get a sense of what I mean, see this editor which lets you interactively construct a treemap: https://beta.observablehq.com/@mbostock/treemap-o-matic https://beta.observablehq.com/@mbostock/treemap-o-matic

mpolichette 8y ago
I'm not arguing against the CST format, but I don't think redundancy is necessarily bad or hard to work with. It can be good because each line is now an independent idea and doesn't require the indentation context, the items can be sorted or moved easily. As for hard to work with... a lot of editors have multi-cursor support these days, which makes editing these things in bulk pretty straight forward for smaller sizes and then there's always sed and awk. ;) Given all that, CST seems like it might be cool for building some quick trees like the given UIs you present. I'd probably keep to to rows for longer storage though.
lsh 8y ago
CSV is just a serialisation format like JSON or XML. CST appears to put the emphasis on readability (not a bad thing!). I've taken to using XSV to pretty-print CSV data in bug reports or feature requests for coworkers who give me CSV or spreadsheets to work with. The data doesn't need to go any further, it's already been processed, it just needs to be clearer to understand than raw CSV/JSON/XML: https://github.com/BurntSushi/xsv https://github.com/BurntSushi/xsv (link has examples of pretty-printed CSV)
siddboots 8y ago
Something that I've used in the past: store the hierarchical data as a breadcrumb-like string in an ordinary column. This means the parsing is just ordinary csv parsing, followed by a relatively trivial extra step to parse the breadcrumb columns. You also retain the ability to describe arbitrary depth hierarchies: country,value World/Asia/China, 1409517397 World/Asia/India, 1339180127 World/Asia/Indonesia, 263991379 An added benefit of this approach is that you can have hierarchies in multiple columns. For example: datetime, source_account, destination_account, amount 2016-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 134.2 2017-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 72.2 2016-07-01, Assets/ProjectFunding, Assets/Capital/Other, 5.0 2016-07-01, Assets/ProjectFunding, Expenses/Development, 4.7 2017-07-01, Assets/ProjectFunding, Expenses/Development, 1.6 2017-07-01, Assets/Cash, Expenses/OPEX, 0.96 2018-07-01, Assets/Cash, Expenses/OPEX, 1.62
- kqr 8y ago
  That has the meta-problem of only allowing two different levels of hierarchies. For one more, you'd have to introduce a new separator. I feel like the fixpoint of this function is going back to only one separator, or something, but I am not seeing the reasoning clearly.

mpolichette 8y ago

I'm not arguing against the CST format, but I don't think redundancy is necessarily bad or hard to work with. It can be good because each line is now an independent idea and doesn't require the indentation context, the items can be sorted or moved easily. As for hard to work with... a lot of editors have multi-cursor support these days, which makes editing these things in bulk pretty straight forward for smaller sizes and then there's always sed and awk. ;) Given all that, CST seems like it might be cool for building some quick trees like the given UIs you present. I'd probably keep to to rows for longer storage though.

lsh 8y ago

CSV is just a serialisation format like JSON or XML. CST appears to put the emphasis on readability (not a bad thing!). I've taken to using XSV to pretty-print CSV data in bug reports or feature requests for coworkers who give me CSV or spreadsheets to work with. The data doesn't need to go any further, it's already been processed, it just needs to be clearer to understand than raw CSV/JSON/XML: https://github.com/BurntSushi/xsv https://github.com/BurntSushi/xsv (link has examples of pretty-printed CSV)

siddboots 8y ago

Something that I've used in the past: store the hierarchical data as a breadcrumb-like string in an ordinary column. This means the parsing is just ordinary csv parsing, followed by a relatively trivial extra step to parse the breadcrumb columns. You also retain the ability to describe arbitrary depth hierarchies: country,value World/Asia/China, 1409517397 World/Asia/India, 1339180127 World/Asia/Indonesia, 263991379 An added benefit of this approach is that you can have hierarchies in multiple columns. For example: datetime, source_account, destination_account, amount 2016-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 134.2 2017-07-01, Assets/ProjectFunding, Assets/Capital/Delivery, 72.2 2016-07-01, Assets/ProjectFunding, Assets/Capital/Other, 5.0 2016-07-01, Assets/ProjectFunding, Expenses/Development, 4.7 2017-07-01, Assets/ProjectFunding, Expenses/Development, 1.6 2017-07-01, Assets/Cash, Expenses/OPEX, 0.96 2018-07-01, Assets/Cash, Expenses/OPEX, 1.62

kqr 8y ago
That has the meta-problem of only allowing two different levels of hierarchies. For one more, you'd have to introduce a new separator. I feel like the fixpoint of this function is going back to only one separator, or something, but I am not seeing the reasoning clearly.