Status type uses "oneOf" and should maybe use "anyOf"

[jugonzal07]

https://github.com/open229/ruleset-model-description-schema/blob/438a8c76750940b30c45444a878b9688b23ae7dd/docs229/ASHRAE229.schema.json#L528-L534

Both these enumeration types have "NEW" and "EXISTING". The term oneOf is an XOR or eXclusive OR. This means that a user specifying "NEW" or "EXISTING" for this field would not pass validation since both enumerations are found in SpaceStatusOptions2019ASHRAE901 and GeneralStatusOptions2019T24. Changing the oneOf to an anyOf would correct this scenario:

Documentation referenced on oneOf and anyOf https://json-schema.org/understanding-json-schema/reference/combining.html#oneof

[JasonGlazer]

@nealkruis and @tanaya-bigladder I could use your advice on this. This issue is that I have two enumeration lists that have overlapping items. The YAML syntax is:

Space:
  Object Type: "Data Group"
  Data Elements:
...

    status_type:
      Description: "Choice of new, existing, addition, alteration, etc. for each ruleset."
      Data Type: "(<SpaceStatusOptions2019ASHRAE901>,<GeneralStatusOptions2019T24>)"

Which generates the "oneOf" code shown by @jugonzal07 above and appropriately, it really should be an anyOf. Is there a different YAML syntax that will result in anyOf instead?

If not, I can do a workaround and just not have NEW and EXISTING in the T24 enumeration but that doesn't seem right to me.

This is still older code than is being used for open205 so if something has been fixed to allow this, please let me know.

[nealkruis]

For this specific case, I maintain my suggestion that the enumeration and data group names in the 229 schema should be ruleset agnostic, and the the core part of the schema should "forward declare" enumerations and data groups that have different definitions for different rulesets. In this case the Data Type would be <SpaceStatusOptions> (or something similar). The schema would then effectively change depending on the ruleset you are validating for.

But to your general question: Maybe the "alternative" syntax should translate to "anyOf" all the time? The original use case was for different data groups, which would never be similar enough for something to be valid under both alternatives. Any reason not to, @tanaya-bigladder?

[JasonGlazer]

@nealkruis I think I understand and agree with the "ruleset agnostic forward declare" approach but I don't think the script to generate the JSON schema will work with that yet. It is on my list of stuff to implement. I hadn't thought of the overlap between this issue and that approach. It would probably still be good to resolve this issue. If you or @tanaya-bigladder could point on where in the code base this could be fixed, I would appreciate it.

[weilixu]

I want to follow up with this issue. We currently running into a problem validating the type of the ruleset model instance. The oneOf runs into invalid msg when the RMD is a PROPOSED model. Note: both RulesetModelOptions2019ASHRAE901 and RulesetModelOptions2019T24Com have the enum PROPOSED, which causes the validation error.