Has the possibility of adding a YAML reader been considered in VTK thirdparty? I’d certainly use it due to the human-readable/editable aspects for formulating flexible visualization configuration inputs as a “recipe” (in the conda sense). I see json and xml are fully supported, but no yaml reader currently exist for module developers, yaml-cpp could be an option. Thanks!
What is the actual use case for it? Do we have a file format using it that we’d like to support?
@ben.boeckel thanks for chiming in. As you know, I am part of the adios2 project and one of our goals is to present a way to users to describe their workflow/dataset for viz purposes in a configurable way. So far, I got a very simple XML schema based on VTK XML headers, XML and JSON are already supported in VTK. In that regard, I just wanted to know through this forum if there is enough traction from other projects as we can always experiment with our own applications workflows and datasets. Thanks!
Yaml is very similar to json but json is much more popular and json does not rely on number of whitespaces to define structure of the data. For me, the only nice feature of yaml is that you can add comments (although json developers consider this a mistake, not a feature).
As long as yaml remains a niche format (compared to json) and/or none of the file formats that are important for VTK use it, there is very little incentive to add yaml support to VTK.
@lassoan I agree. Also, support a ThirdParty library adds a maintenance burden.
@lassoan @lorensen thanks for your valuable insight. Just wanted to know the opinion of the VTK community. I had to use yaml as an interesting configuration choice in conda, readthedocs, docker-compose, CircleCI, Azurre, etc. I guess the answer is that there is not enough incentive for VTK’s business needs.
Just trying to compile some pros and cons
- readable and editable configuration format
- ability to add comments and comment out lines with a single #
- add code block
- line breaks
- support for reusing text with anchors
- adds maintenance costs in VTK
- rely on whitespaces
- niche compared to json which is already supported (this is debatable?)
- little incentive by VTK’s major stakeholders
- numerous styles
- implementations have security vulnerabilities
- not used in VTK data formats
I don’t know that I’d call YAML a “niche” thing these days. However, the lack of use of it in data formats that may be supported by VTK (or even in general within the scivis world?) does not lend towards its inclusion into VTK itself.
One of the main problems here is that because YAML is very flexible, there are numerous “styles” that may make the format “unstable” when writing it out between various tools. This is in contrast to JSON where just about the only flexibility one has is “spaces after
:?” and “how much to indent by?”. This is basically a longer way of saying “yes, easily editable by humans, but a pain for machines to edit”. Personally, I feel JSON is pretty close to the middle line on that axis.
In addition to the maintenance burden, YAML is a very complex beast and numerous parsers have had serious security vulnerabilities (though this is mainly due to the dynamic nature of the backing languages in those cases).¹
¹ Yes, I’m aware we have 3 XML parsers in VTK. I’d like to make that 1 at some point, but momentum there is slow.
@ben.boeckel thanks for sharing your views on the topic, it’s always good to hear from the maintainer’s perspective. One thing I might have not formulated correctly is that I’d exploit yaml in configuration files, not the data itself (at least in the domain I am working on). It’s more of a way of providing high-level options to customers in complex workflows since json and xml require a bit more effort to edit. At the same time, I don’t want to pass the burden to VTK if there is no enough adoption of the format (not a big deal really). I edited the pros and cons above from your input. Thanks!