Since YAML does not preserve map ordering, we might have to use list+map scheme (http://yaml.org/type/omap.html) because lack of ordering will make documents badly suited for manual editing.
Unlike JSON, YAML provides tags and anchors, so we may do away with "TYPE" and UUIDs. Although as for ids, it is a bit questionable. How should we link to nodes inside other files? Should it be via separate "naming node" mechanism or should it use anchors?
Since YAML does not preserve map ordering, we might have to use list+map scheme (http://yaml.org/type/omap.html) because lack of ordering will make documents badly suited for manual editing.
Unlike JSON, YAML provides tags and anchors, so we may do away with "TYPE" and UUIDs. Although as for ids, it is a bit questionable. How should we link to nodes inside other files? Should it be via separate "naming node" mechanism or should it use anchors?
For now, lets postpone final decision on external linking, but assume that it can be implemented with "naming nodes" and so we do not need uuids for that reason. However, we might still want uuids to generate consistent anchors..
For now, lets postpone final decision on external linking, but assume that it can be implemented with "naming nodes" and so we do not need uuids for that reason. However, we might still want uuids to generate consistent anchors..
use additional filter step when saving file (quite complicated: to preserve comments: diff old and new versions and undo whitespace/comment changes; to preserver anchors: parse with anchor-preserving parser and replace??)
accept lack of preservation
Anchor preservation is actually more important because lack of it would mean constant changes of file that would produce noise in diffs.
Lack of comment preservation only means that human readability/writeability is reduced, but even then comments might be embedded into nodes at some point. And also solution 3 is much easier to implement for comments.
Bah, there seems to be no C/C++ yaml library that would support comment and anchor preservation.
- <https://github.com/jbeder/yaml-cpp/issues/110>
- <https://github.com/jbeder/yaml-cpp/issues/457>
- <https://github.com/yaml/libyaml/issues/42>
Possible solutions:
1. write yaml parser/emitter (requires lots of work)
1. fix issues and use fixed parser/emitter
1. use additional filter step when saving file (quite complicated: to preserve comments: diff old and new versions and undo whitespace/comment changes; to preserver anchors: parse with anchor-preserving parser and replace??)
1. accept lack of preservation
Anchor preservation is actually more important because lack of it would mean constant changes of file that would produce noise in diffs.
Lack of comment preservation only means that human readability/writeability is reduced, but even then comments might be embedded into nodes at some point. And also solution 3 is much easier to implement for comments.
caryoscelus
Before this is implemented, we need to specify anchoring and importing mechanisms (that's why we have current JSON+UUID abomination).
Since YAML does not preserve map ordering, we might have to use list+map scheme (http://yaml.org/type/omap.html) because lack of ordering will make documents badly suited for manual editing.
Unlike JSON, YAML provides tags and anchors, so we may do away with "TYPE" and UUIDs. Although as for ids, it is a bit questionable. How should we link to nodes inside other files? Should it be via separate "naming node" mechanism or should it use anchors?
For now, lets postpone final decision on external linking, but assume that it can be implemented with "naming nodes" and so we do not need uuids for that reason. However, we might still want uuids to generate consistent anchors..
Bah, there seems to be no C/C++ yaml library that would support comment and anchor preservation.
Possible solutions:
Anchor preservation is actually more important because lack of it would mean constant changes of file that would produce noise in diffs.
Lack of comment preservation only means that human readability/writeability is reduced, but even then comments might be embedded into nodes at some point. And also solution 3 is much easier to implement for comments.
Ok, yaml-cpp seems to be easily fixable (anchor part), so lets use it for now.