[meta issue] hxlm

[fititnt]

This issue will be used to reference commits from this repository and others.

TODO: add more context.

---

Update 1 (2021-03-01):

Ok. I liked the idea of YAML-like projects!!! But may be easier to do the full thing than explain upfront. (I'm obviously biased because of Ansible, but ok; anyway I know is possible to even implement testinfra; but would be easier to create an "Ansible for datasets+ (automated) compliance" than reuse Ansible)

Also YAML, different from JSON, is much more Human friendly (for example: it allows comments!) so this can somewhat help.

Being practical, at this moment I think mostly will be wrapper to libraries and APIs already existing (aka syntetic sugar, not really new features). But as soon as the building blocks are ready, the YAML projects themselves become powerful!

[fititnt]

Ok. I think I will give up the idea of trying to make the code generate an Schema of what is on disk

but do the opposite: let YAML describle what is on disk (or what should be the final state of what would be on disk).

Turns out that this remember a lot about Ansible playbooks! but instead of entire group of servers, is an group of datasets on local disk! But even if on next days each of these points like hdatasets, hfiles, etc on the YAML inventory are already mapped to action classes, there would still be missing the equivalent of "ad-hoc" ansible tasks. The Ansible ad-hoc tasks would be what on HXL the name of these are recipes:

• https://github.com/HXLStandard/hxl-proxy/wiki/JSON-recipes (exact equivalent)
• https://github.com/OCHA-DAP/hxl-recipes (not exact, but still recipe)

Why YAML over JSON

At this moment, I think that the main difference here over just use ad-hoc HXL-proxy recipes are the fact to start to have an inventory. Ansible separes what is inventory and what is task (so this can be used for several projects that are somewhat similar).

But the main idea that started to look at YAML was not even this about Ansible, but I remembered that YAML is easier to deal with comments, while still powerful to process via tools.

Special attention to the concept of compliance (this is likely to take months)

Do exist some building blocks to abstract, but one special attention to in the end come with an descriptive language easier to abstract is the concept of compliance rules. So we're not only talking here about have one common way to express concepts, but needs to be on local language and needs to support spaces, accents, etc, also on the key terms (not only on values).

compliance rules is somewhat the idea of compute an result of if something is authorized or not and what to do if is not authorized. Other thing could be compliance rules apply filters or at least require that the human ask permission of someone why some specific filter does not apply to some case. But in an scenario where people trust more an computer than each other (or actually trust each other, but need some explanation to not break laws that would need weeks or months to get clearance), if who approves feel safe about what is on an YAML compliance file and do exist people outside the organization that grant that it at least reduce human error and eventually allow faster data exchange for more sensitive contents.