Ideally, we can provide a vendor with a single schematron file that is free of dependencies, containing all checks that should pass before delivery.
To accomplish this, we should create a new, standalone, base schematron with checks for the vendor, and then handle subsequent layers via additional schema. Instead of the <extend> element, we can define schema sets via oXygen's Schema Association feature, which we already use to associate multiple schema files with a directory.
[ ] Identify which schema checks we want vendors to perform before delivery
[ ] Move needed checks in and move unneeded checks out, ensuring no <extend> element is in the base schema
[ ] Notify vendor of availability of new schema
[ ] Create schema associations for our default checks
Currently, frus.sch references another schematron file, by means of an
<extend>
element. See https://github.com/HistoryAtState/frus/blob/master/schema/frus.sch#L19. As a result, vendors need this additional file to be able to validate FRUS files for delivery.Ideally, we can provide a vendor with a single schematron file that is free of dependencies, containing all checks that should pass before delivery.
To accomplish this, we should create a new, standalone, base schematron with checks for the vendor, and then handle subsequent layers via additional schema. Instead of the
<extend>
element, we can define schema sets via oXygen's Schema Association feature, which we already use to associate multiple schema files with a directory.<extend>
element is in the base schema