[repository schema] Explicit type scenarios for fields and type scenario overrides for fieldRefs

[erakadjiev]

This PR is a follow-up to the discussion we had on #171 and in iMeetCentral. It addresses the following 2 points:

1. The scenario for the data type or the code set should not be implicitly set to the same scenario of the field anymore. Instead, it should be specified in one of the new typeScenarioId and codeSetScenarioId attributes. The reason for this change is that the current implicit link 1) is inconsistent with the rest of Orchestra where a missing scenario specification means "base" scenario, 2) limits the ability of having a field with scenario X point to data type or code set with scenario Y, and 3) causes confusion and mistakes for developers working with Orchestra.
2. Ability to override data type or code set scenario in field references. We would like to allow overriding of typeScenarioId or codeSetScenarioId in field references, but still keep scenarios for field definitions and field references. This would allow 1) having just a single field definition and field references with typeScenarioId/codeSetScenarioId overrides (suggested by @kleihan as a way to simplify creating of new Orchestra-based specs), 2) having multiple field scenarios for reasons other than just each pointing to a different type/code set scenario, and 3) remain more backwards compatible with 1.0 (at least in the sense that field scenarios will not need to be removed).

I have some questions related to those changes.

• [Related to point 1] Can you please double-check that the key constraints defined in repository.xsd prohibit having a mix of type+codeSetScenarioId or codeSet+typeScenarioId?
• [Related to point 2] I've added only the changes to repositoryTypes.xsd. How can we define the following key constraints in repository.xsd?
  • For all fieldRefs (I assume the selector would be .//fixr:fieldRef on the repository level).
  • If a typeScenarioId or codeSetScenarioId is specified (how can we define this optionality?)
  • Make sure that it is a valid scenario for the referenced field definition's type or code set (how can we resolve the referenced field defintion's type/codeSet?)
• [Related to PR 171 and point 1] In fieldRuleType, there's an override for type. Shouldn't there be then also overrides for codeSet, typeScenarioId, codeSetScenarioId? I.e. in fieldRuleType shouldn't we replace type with the new fieldTypeAttribGrp?
• [General] Should we rather switch to using typeId/codeSetId (similar to how we do for scenarios and other elements that rely on refidGrp), or we'll stick to referencing the data type/code set by name only?

[erakadjiev]

Hello @donmendelson @kleihan

Sorry for the delayed response! I've added an example XML file that demonstrates the new attributes for type scenarios. I also noticed that the schema was missing the data type scenario attributes for code sets. I've added that too.

Please take a look when you have a chance. Please also check the questions from my initial comment. Thank you!

[kleihan]

Could we simplify this by constraining to either (type or codeSet) plus typeScenarioId that would apply to either a datatype or codeset? One less attribute.

I removed my earlier comment as I think I misunderstood the proposal. How does a typeScenarioId apply to either a datatype or codeset? If attributes codeSet and codeSetScenarioId are present but type and typeScenarioId are not, how does the constraint apply technically? Is this what it would look like?

         <xs:key name="typeCodeSetKey">
        <xs:selector xpath="."/>
        <xs:field xpath="@type|@codeSet"/>
        <xs:field xpath="@typeScenarioId"/>
    </xs:key>