Schema Rules

[kinlane]

I'm starting a read for aggregating conversations at the granular level. The looseness or strictness of how the JSON schema interprets HSDS or HSA.

[kinlane]

Nate Plumley: Looking at the HSDS spec, i see that program, service, and location, all have a reference to a parent organization (organization_id). I have 2 questions about this:

1) In the spec, organization_id in the location object is listed as optional but has the following comment "Each location entry should be linked to a single organization." I just wanted to confirm that it is in fact optional.

2) Should the API implementation enforce that related services and programs and services and locations have the same organization_id. In particular:

2a) if service S is in program P (S.program_id = P) then S.organization_id === P.organization_id 2b) if service S is in location L (S,L in service_at_location) then S.organization_id === L.organization_id

Source: https://openreferral.slack.com/archives/C4Z5DFZ1S/p1498757419428066

[kinlane]

benjkamm nplumley: Based on our experiences, yes, all records under a single organization_id should be enforced to reference it consistently.

[kinlane]

kinlane From my vantage point the specification isn't enforcing or providing guidance on any of these relationships at the moment. I'm neck deep in the JSON schema phase of validation, which will have this level of granularity for dictating, and I look for ya'll to provide guidance on the looseness or strictness of ruling at this level, and I'll make reflect in JSON Schema which will become the official HSDA/S definition of "compliant".

[NeilMcKLogic]

@kinlane @boxfoot @nplumley Alot of the object relationships and requirements were discussed and decided upon during the HSDS 1.1 cycle led by @timgdavies , including the ones cited above.

I do agree that an HSDA implementation should enforce those HSDS requirements and relationships, particularly for incoming data (Updates, Inserts) lest it gets corrputed/HSDS-invalid data. It would be a good idea to note that in the HSDA documentation, as well as include it in the Validators that @kinlane mentioned he is building.

[mrshll1001]

We will be archiving this repository soon. We're closing this issue because we believe it has been conclusively addressed as part of work on the main HSDS standard.

In this case, HSDS 3.0 has implemented a schema. Any changes to the rules should be discussed in the forum, prioritised, and tackled as part of future upgrades.