We have looked into this a bit more today and had a few more observations (especially when we hit yet another problem, now with /context/other_context !)
Our theory is that at some level (generating a Web Template? or maybe in other places as well?) there is an intrepretation happening where, at a minimum,
- “/category” is expected to have a DV_CODED_TEXT child without node_id specified
- “/context” is expected to have a child EVENT_CONTEXT without node_id specified
- “/context/other_context” is expected to have a child ITEM_TREE with node_id = at0001
It seems like this is generally the case for many of the different specialized Composition archetypes but not for all of them, and especially not for some of the “newer” ones that we are looking at.
For example, openEHR-EHR-COMPOSITION.report-result.v1 seems to follow this pattern, but not openEHR-EHR-COMPOSITION.self_reported_data.v1, which instead looks like this:
- “/category” has a DV_CODED_TEXT child with node_id at0001 (instead of blank)
- “/context” has a child EVENT_CONTEXT with a node_id at0002 (instead of blank)
- “/context/other_context” has a child ITEM_TREE with node_id = at0003 (instead of at0001)
And then when these kind of differences happen, we don’t seem to get the “normal” paths for these nodes in the Web Template, and then have this problem/confusion when we try to write compositions and build more standardized tooling.
@thomas.beale Does it seem right/ok to have different node_ids for these different specialized Compositions (e.g. sometimes other_context can be at0002, at0003, etc) or does it seem more that all types of compositions should follow the same pattern when it comes to node_id for these nodes?
And as a follow-up question, does it seem reasonable that we should be able to expect for example to “always” write to /context/ and /category (etc) in FLAT format, or that we should instead expect to get different paths for these in every new Web Template (depending on the template itself and its own node_ids)?