Closed opoudjis closed 1 year ago
It is urgent: now that payloads are validating, aliases are also not being recognised for LocalId, FTE, StaffPersonalRefId, etc: 117 distinct fields generating "property type must be object", and accounting for 3612 warnings.
Have resolved the $ref for these aliases, now to resolve the types as well
At long last, almost done. The only remaining property type must be object
that are PESC and not Goessner are:
DebitOrCredit is an extension (MonetaryAmount = value + attribute, to which is added an attribute, just like with NameOfRecord). We just didn't know about that, so didn't mark it up as such.
Needed to detect List of Element + Attribute, and treat that as list of objects.
An issue with the Specgen XML conversion is that the received script has been naive about working out whether a type is a string or an object: it has assumed in places that all CommonTypes are objects, which means it is not coping well with complex types based on codesets (https://github.com/nsip/specgen_input_au/issues/49). Moreover, JSON Reference does not tolerate multiple levels of indirection on $ref, meaning that aliases are not permissible in JSON Schema (https://github.com/nsip/specgen_input_au/issues/48). As a result, I have hard coded IdRef, RefId and LearningResourcePackage as aliases in a lookup function applied to $ref values. I've also started eliminating alias types from the underlying specgen XML.
That is not going to scale though, and I'm dreading the prospect of handing the stylesheet over to @4pins and having him sort through the aliases in the US spec, which will be more abundant. For that reason, I'm going to implement a more sophisticated lookup function (or get @joerghuber to), which follows $ref links until they bottom out, if the $ref is the only item in the element, and take that as the reference value:
This is not urgent, and I'll work through the other issues first, but it needs to be done for generalisability.