Tag Archives: configuration

Hidden previews

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 hide property:

"preview": [{
    "xsl": "edm2ese.xsl",
    "label": "ESE",
    "output": "xml",
    "hide": true,
    "preview": [{
        "xsl": "ese2html.xsl",
        "label": "Europeana",
        "output": "html"
    }]
}]

In this example, Europeana will be generated based on ESE, but ESE will be hidden.

Schematron support

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):

<element name="Aggregation">
  <complexType>
    <annotation>
      <documentation>Aggregated CHO: a link to the original CHO plus a new provider</documentation>
      
      <appinfo xmlns:sch="http://purl.oclc.org/dsdl/schematron">
        <sch:pattern name="Either Is shownby or is shownat should be present" >
          <sch:rule context="ore:Aggregation">
            <sch:assert test="edm:isShownAt or edm:isShownBy">A ore:Aggregation must have either edm:isShownAt or edm:isShownBy</sch:assert>
          </sch:rule>
        </sch:pattern>
      </appinfo>
      
    </annotation>
    ...

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

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 JSONArray:

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 getXSL method.
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);		

Preview configuration can use Crosswalks

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:

{
    "xsl": "lido-v1.0-to-ese-v3.4-transform-v3.xsl",
    "label": "ESE",
    "output": "xml"
}

we can use this:

{
    "target": "ESE 3.4",
    "label": "ESE",
    "output": "xml"
}

The 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).

Mint2 local.properties for local configuration

In order to avoid mint.properties cluttering of test configuration properties, I modified the Config class to support an additional properties file calledĀ local.properties. Properties in local.properties have higher priority than custom.properties (which have higher priority than mint.properties). They should not be submitted to the SVN repository and they should be used for local tests during development. They are not required for a Mint2 installation and they will be ignored if missing or empty.