THis needs to be relaxed according to needs identified by implementers and described in
I also think we should just go ahead with this.
Agreed. It should not have any backward compatibility issues since any current AQL would simply not be able to reference 'context'.
Good, go ahead!
Reading duplicate comments I thought we should also indicate somewhere in specs how should we than consider/detect persistent compositions in the new situation (see comments):
heath.frankel Heath Frankel added a comment - 17/Mar/16 8:53 AM
My concern with a new code is then deciding which composition archetypes are persistent or episode_persistent, take care plan for example.
If the invariant is removed/changed to 0..1, then we can use the rm_version to determine if we should be enforcing 0..0 or allowing 0..1. We are opening the constraint which should be more acceptable than closing the constraint, it only affect new systems sending to old systems. We shouldn't be holding back progress.
I have completed the work on this now. Please see the links in the 'Execution' tab above. The changes are the most minimal possible, rather than changing a lot of text to do with e.g. Composition.category, which will need to come later.
NB: normally 'acceptance' should only be made when you agree with the actual changes.