Preview configuration properties support hidden views. They will be used to generate subsequent views, but they will not appear in the UI.
To hide a view add the
In this example, Europeana will be generated based on ESE, but ESE will be hidden.
Mint2 now supports validation using Schematron rules. Schematron rules are related to an XmlSchema instance and can be provided to the system through
appinfo schema annotations, using external schematron files, or both.
Define schematron rules
You can define schematron rules inside an XSD by adding an
appinfo annotation like this (example from ORE.xsd):
<documentation>Aggregated CHO: a link to the original CHO plus a new provider</documentation>
<sch:pattern name="Either Is shownby or is shownat should be present" >
<sch:assert test="edm:isShownAt or edm:isShownBy">A ore:Aggregation must have either edm:isShownAt or edm:isShownBy</sch:assert>
Alternatively, you can provide schematron rules using external schematron files. If the
schematron schema configuration property is defined, the system will first try to locate this file in the same directory the XSD file exists. Otherwise it will try to locate a file with the same name as the XSD file with a .sch suffix (i.e. EDM-INTERNAL.xsd.sch). The system will also try to merge rules defined from xsd and external files.
Schematron validation is available by using the
gr.ntua.ivml.mint.xsd.SchemaValidator class. This class provides variants of the
validateSchematron(Source source, XmlSchema schema, ReportErrorHandler handler) method to validate source using an XSL generated by the schematron rules related to the schema XmlSchema. If a handler
ReportErrorHandler is provided, errors will be added in the handler’s schematronErrors
Schematron XSL generation
The schematron XSL used to validate an xml is generated by the
gr.ntua.ivml.mint.schematron.SchematronXSLTProducer class by using the
This requires a string that contains a complete schematron document. Rules from XSD appinfo annotations can be wrapped in a complete schematron document by using the
wrapRules method and using the schema’s namespace declarations (from schema’s configuration) to include in the document:
XmlSchema schema = <an XmlSchema instance>
String schematronRules = schema.getSchematronRules();
SchematronXSLTProducer schematron = SchematronXSLTProducer.getInstance();
String wrapped = schematron.wrapRules(schematronRules, schema.getConfigurationNamespaces());
String xsl = schematron.getXSL(wrapped);
I added the option to use Crosswalks in preview configuration. For example, instead of specifying the lido to ese XSL file in each preview configuration (and having to update it each time it was changed) we can instead provide the target schema name in the preview. Instead of using this preview configuration:
we can use this:
"target": "ESE 3.4",
ChainTransform object that generates the preview tabs will look for a direct crosswalk from the source schema to the specified target. This should use the same crosswalk used during publication, if the publication schema and preview schema names are the same. So we should be consistent on how to name installed schemas in Mint2 installations. I suggest we use the schema name in capital letters followed by the version (without a ‘v’ prefix) i.e. LIDO 1.0, ESE 3.4.
PS 1. If you omit the label parameter the preview tab will use the target schema name as tab title.
PS 2. In order to update our mint2 installations accordingly, I added the option to rename a schema in Administration > Manage XSDs (see here).
When setting up a new XSD schema, Mint 2 executes the following steps:
- Gets the requested XSD from a path relative to paths.schemas directory defined in mint.properties.
- Looks for available configuration in the same directory as of the XSDs, with the same name plus the .conf suffix (If such a file does not exist, it attempts to generate basic configuration properties automatically).
- Parses the XSD and generates a mapping template based on the schema configuration file. This template is stored in the jsonOriginal property of the XmlSchema database object.
- Parses annotations in the XSD to generate schema documentation, available in the mapping editor. The result is stored in the schema’s documentation property.
- If a customization Groovy script is defined in the configuration file (through the customization property), it loads the script and runs it with this mapping template as input. The result is stored in the jsonTemplate property, which is used to create a new mapping. If no script is defined, jsonOriginal is copied in jsonTemplate.
This process is controlled from the Home>Administration>Manage XSDs page, which uses the OutputXSD action and schemasummary.jsp. Already processed schemas appear there with the following control options:
- Rename schema. Use this to rename the schema entry.
- Reload for mapping. Use this if the XSD has changed and you want to start the process from the beginning.
- Reapply configuration. Use this if only the schema configuration or the customization Groovy script have changed and you want to reconfigure the mapping template. It will use the already stored template in jsonOriginal and will take significantly less time since it will not parse the XSD schema. Note that if the item configuration property has changed then you have to use the Reload option because parsing is needed to generate a template for the new item root.
- View XSD. Shows the filename of the XSD.
- View schema configuration properties. View configuration properties stored in the database for this schema. These are also used by mappings at all times (even if created before this version of the configuration file was loaded).
- View original template. View the mapping template generated by the parser, before any customization applied.
- View customized template. View the customized mapping template that is used to create a new mapping.
- Edit template. This is an experimental feature to allow editing of the customized jsonTemplate using the mapping editor. Currently it is possible to modify the template, but changes will be lost if you reapply configuration.
A schema’s preview configuration now supports XSL parameters. This was implemented to support, for example, the provider parameter in LIDO to ESE XSL. Parameters are currently supported only in preview tabs that have an ‘xsl‘ field. In order to add parameters, a new JSON array called ‘parameters‘ is used in the preview configuration for the specific preview tab. This array contains parameter objects with three fields:
- name: The parameter name.
- value: Controls the value of the parameter in the XSL, based on the parameter type (see below)
- type: Type of the parameter. Currently supports two options:
- constant: Constant value parameters. The parameter will always have the value of the ‘value‘ field.
- mint: Mint defined parameters. The parameter will have the value of the mint property specified by the ‘value‘ field.
An example of the parameter’s configuration, from lido-v1.0-proxy.xsd.conf: