I think that, if the format is carefully designed (and, again, I’d love to be inspired by IMF CPL logics), it should be possible to have both:
- a simpler syntax where just one change is indicated (and overwritten every time),
- whereas a history or revisions may also be stored (as part of a pedigree)ò
This way a “consumer” application which doesn’t support such versioning just skips the parsing of pedigree part when an ACESclip is read. It just honors the ACESclip at its current state, without its full history of revisions or cases.
How to do this? From my previous suggestion in “What is ACESclip?” thread (I know it was a damn long post, not many read it probably):
ACESclip may be generated as early as near-set or upon ingestion by the post facility) and may be modified in later stages (image pre-processing, pre-grading, color-grading, compositing, finishing, mastering).
[…]
I suggest every update is associated to a UUID that is reported as an attrivute to any element added or modified during that update. In a final part of the ACESclip a list indexed by those UUIDs reports logged data for each update, such as, at least:
- date/time of the change
- hostname, username, OS (+version) and software application (+ version) doing the change
- optional comments/notes that can be hand-filled
On the next topic I’ll post a sample strawman of the above concept on the original example ACESclip XML from Appendix A of TB-2014-009.`