TDYCARHugh
commented
20 hours ago I made an xsd from the FC after fixing the issue in https://github.com/iho-ohi/S-128-Product-Specification-Development/issues/2
The sample file had to be altered to remove the encodingFormat attribute from the sample S100Service.
The sample file then validates with the attached xsd which is provided as an example XSD provided as is without commitment. S-128_XSDExample.zip
An initial look into the gml xsd provided with S-128 v2.0.0 release candidate (2024-11-22).
The XSD validates by itself but does not work with the sample gml because there are problems with the xsd. The sample gml appears ok and validates with an xsd which is based on the previous FC.
Issues found, so far, with the provided xsd.
The 'code' attribute not included in definition of enumerated attributes. This is expected to be in S-100 GML.
The bindings for mandatory attributes are not including the possibility to be set to Unknown. nillable='true' is not included in bindings to mandatory attributes.
The order of attribute and sub attribute bindings is expected to follow the order in the FC. Issue with ordering of sub elements such as in timeIntervalOfProductType. The xsd has expirationDate, issueDate, issuanceCycle. Should be same order as in FC bindings which is issueDate, expirationDate, issuanceCycle.
A problem reported on the previous iteration still exists where the xsd is constructing classes derived from abstract types which is causing an incorrect order of attributes and associations in the derived types. In the final definition all the attributes should be bound before the associations.