Applying extra Schematron validation to DITA

[tcleghorn]

I need to set up an extra layer of Schematron "house style" type validation on a DITA authoring and content management system. Authors are using Ixiasoft's DITA-CMS and TextML products, with Oxygen Author 17.1 (plus Ixiasoft's extensions) as an Eclipse plugin, but we (i.e. admins/devs) need to be able to see the same results as the authors in the standalone Editor (not necessarily the same version..!) without extensions. We're struggling to arrive at an ideal setup, on a number of levels.

On the infrastructure side, we started with a side-channel approach, distributing a single .sch file to users, and requiring them to manually edit the DITA validation scenarios in their own environment, but this is cumbersome and error-prone, unsurprisingly; we next tried hosting the .sch file in the TextML docbase (which doesn't sit right with me, personally speaking - it seems like it'll lead us to weird snarl-ups with potential future modularity, among other things), but this still requires manual intervention from users, and feels likely to cause obstacles for development outside the Ixiasoft system.

As far as actual usage goes, we have also found distinct differences in results - although I expect a lot will be down to local configuration inconsistencies, we've observed, among other puzzles:
- one user's Eclipse "Results" pane displaying only the results with role 'error' or 'warn', but not 'info', while another displays the opposite;
- unexpected "[Jing] SAXParseException - root element of schema must have a namespace" error

Our ideal world would involve minimal manual configuration and predictable in-editor behaviour for users, and simple deployment procedures for us. We realise there'll be Ixiasoft considerations in play, but what would be the gold-standard means of achieving this from a pure Oxygen perspective? We're particularly keen to figure out our best option for hosting the ruleset, as this is pretty much a prerequisite for anything moving forward.

[Radu]

Hi,

Please see some answers below:

- one user's Eclipse "Results" pane displaying only the results with role 'error' or 'warn', but not 'info', while another displays the opposite;

One of my colleagues tested with a 17.1 installation and indeed in presented INFO messages in another tab. So the error and warning messages are in the "Problems" tab and the "Info" are directed to an Oxygen specific result tab.
This was changed in Oxygen 18.1 which properly highlights Schematron INFO messages in the editing area and also presents the infos along with the errors and warnings in the same tab.
So you should consider upgrading Oxygen.

- unexpected "[Jing] SAXParseException - root element of schema must have a namespace" error

Probably they did not properly configure the validation scenario, when they added the extra validation unit in the DITA validation scenario, the Schematron schema was somehow specified as being Relax NG, or something like this...

Our ideal world would involve minimal manual configuration and predictable in-editor behaviour for users, and simple deployment procedures for us. We realise there'll be Ixiasoft considerations in play, but what would be the gold-standard means of achieving this from a pure Oxygen perspective? We're particularly keen to figure out our best option for hosting the ruleset, as this is pretty much a prerequisite for anything moving forward.

Validation scenarios can also be exported to XML and then imported by others. But scenarios point to various schemas and Schematrons and those would need to be copied as well...
From what I remember Ixiasoft has ways to provide custom framework configurations to the Oxygen plugin. So Ixiasoft can force the Oxygen plugin to load its frameworks from another location, location which from what I remember Ixiasoft could synchronize with the remote CMS.
Usually in such cases you would extend the DITA framework and create your own framework folder extension:

http://blog.oxygenxml.com/2015/08/docum ... aring.html

and then somehow the framework folder extension needs to be shared, and you can either to this by sending the folder to everyone and having them refer to the folder in the Oxygen plugin Preferences->"Document Type Association->Locations" page or somehow use Ixiasoft mechanisms to distribute a framework (and for this you can probably contact and ask them).

Regards,
Radu

[tcleghorn]

Thanks Radu - there were a couple of things I didn't explain properly though, sorry!

Regarding the info/errors display, both users had the Oxygen 'Results' pane correctly, but one only had an 'Info' tab, while the other had only 'Errors'. In both cases, this was within Eclipse, not in the standalone Editor. Noting that you mention improvements to Schematron in v18 (unfortunately it's not clear at the moment whether we should expect to be able to upgrade the Oxygen plugin independently), is it possible that this problem would be related?

The Jing error is actually on my own machine - first thing I checked was whether I'd accidentally left the wrong schema type specified! Any advice on where I could go digging for further info on this? It's just a minor nuisance for me, but I think it would be confusing for our users, so it'd be good to pin it down.

Regarding Schematron hosting, would you actively advise any particular method? My own feeling is that serving it over HTTP will be the most flexible, but there are ongoing debates here..!

[Radu]

Hi Tom,

Please see some answers below:

Regarding the info/errors display, both users had the Oxygen 'Results' pane correctly, but one only had an 'Info' tab, while the other had only 'Errors'. In both cases, this was within Eclipse, not in the standalone Editor. Noting that you mention improvements to Schematron in v18 (unfortunately it's not clear at the moment whether we should expect to be able to upgrade the Oxygen plugin independently), is it possible that this problem would be related?

So this issue cannot be reproduced for all end users right? I would again suggest upgrading to Oxygen 18.1. In 18.1 we took special care to properly present and highlight Schematron INFO messages. And they can also come with quick fixes.
AFAK DITA CMS 4.3 officially supports Oxygen 18.1, I do not know if another DITA CMS version does, you would need to ask them.

The Jing error is actually on my own machine - first thing I checked was whether I'd accidentally left the wrong schema type specified! Any advice on where I could go digging for further info on this? It's just a minor nuisance for me, but I think it would be confusing for our users, so it'd be good to pin it down.

If you edit the DITA (or DITA extension) framework configuration that you already modified, in the "Validation" tab you can select the validation scenario that you have modified (I'm assuming you edited the default "DITA" validation scenario and added another validation module to it) and there is a button there which allows you to export the selected validation scenarios to an XML file. Then you can zip the XML and attach it to an email, I could look into it on my side (support@oxygenxml.com).

Regarding Schematron hosting, would you actively advise any particular method? My own feeling is that serving it over HTTP will be the most flexible, but there are ongoing debates here..!

I would suggest the framework extension mechanism that I previously recommended. If you want to keep the Schematron on a web server, this could also be a solution. From what I remember, automatic validation (which is done every time you type) should only load the Schematron once from the HTTP server, then it should reuse the already processed Schematron set of rules on subsequent modifications. So Oxygen should not download the schema whenever any modification occurs, it should do this only once when the first automatic validation is done.

Regards,
Radu