Arising from #30, it occurs to me that we have a situation where the set of syntactic and semantic constraints in this and the other EBU-TT XSD repos can:
be partially validated with an XML Schema 1.0 XSD
be validated with more precision with a "simple" XML Schema 1.1 xsd
be validated with significantly more additional precision by also including Schema 1.1 xs:assert elements to check particular details
Additionally, different levels of strictness are needed for different usage contexts. For example, some users would likely want to enforce the EBU-TT Part 1 v1 or v1.1 metadata constraints of element ordering and some may want to enforce the placement of facet elements vs documentFacet elements in the document hierarchy.
One approach we could consider here is to make this repo build the different permutations of XML Schema for these different dimensions, instead of being a static set of XSDs. We could pre-build them as a CI step and publish the built artefacts using GitHub pages and publish them with known URIs.
This would be quite a big change for this repo, which would then consist of source code whose output is the appropriate set of XSDs for a given set of input parameters. I'm posting this issue to hold the thought that this is a potential option for us, rather than with any intent of taking immediate action. Views welcome!
Arising from #30, it occurs to me that we have a situation where the set of syntactic and semantic constraints in this and the other EBU-TT XSD repos can:
xs:assertelements to check particular detailsAdditionally, different levels of strictness are needed for different usage contexts. For example, some users would likely want to enforce the EBU-TT Part 1 v1 or v1.1 metadata constraints of element ordering and some may want to enforce the placement of
facetelements vsdocumentFacetelements in the document hierarchy.One approach we could consider here is to make this repo build the different permutations of XML Schema for these different dimensions, instead of being a static set of XSDs. We could pre-build them as a CI step and publish the built artefacts using GitHub pages and publish them with known URIs.
This would be quite a big change for this repo, which would then consist of source code whose output is the appropriate set of XSDs for a given set of input parameters. I'm posting this issue to hold the thought that this is a potential option for us, rather than with any intent of taking immediate action. Views welcome!