Oxygen XML Forum

Hi,

I'm struggling defining validation scenarios for a project (I'm using an XPR file in Oxygen-22). I've created a Schematron file with two phases:

• a "light" phase, which only checks for structural properties

• a "full" phase, which checks for structural properties and substantive properties

The idea is that the "light" scenario could be used for batch transformation tasks, while the "full" scenario could be used for single-file validation.

The Schematron phases are working as they should, but I have troubles with associating these transformations in Oxygen. Both batch and single-file validation scenario associations seem to influence each other, and it's not clear how to define a default scenario.

I'll try to explain with some observations. I have defined both transformation scenarios in the "validation" tab of the "document type" settings, and set the "full" scenario (the first) as default:



When validating a single file, this indeed applies the "full" validation scenario.

Next, I select a project folder in the project view, and select the "light" scenario via the "Configure Validation Scenarios" context menu:



After clicking "Save and close", I can see how a batch validation indeed only applies the "light" validation scenario to the selected files.

Yet, afterwards, I notice this "light" validation scenario is applied as well when validating single files. In other words, the validation scenario association of the batch transformation seems to override the "default" validation scenario association set in the XPR file. Yet, the document type settings still list the "full" scenario as the default validation scenario.

What makes it even more confusing, is that, when I configure the validation scenario for that individual file to the "full" validation scenario again, this association seems to be limited to that single file. When I execute another batch validation run, I see how the "light" validation scenario is applied to all files, except to that file for which I had re-associated the "full" scenario. This makes the associated validation scenarios a mixed bag, making it unpredictable which scenario will be applied to which files (and hence, whether the files really adhere to the most comprehensive validation rules). Moreover, it seems unclear to me how the "default" validation scenario (as defined for the document type in the XPR file) can be restored.

In summary, I would like to know if it is possible to associate different validation scenarios to different validation modes (single-file vs. batch), and keep these associations fixed. Apologies if I'm overlooking something obvious.

Kind regards,

Ron

Hi,

Ron Van den Branden wrote: ↑Thu Mar 26, 2020 12:07 am In summary, I would like to know if it is possible to associate different validation scenarios to different validation modes (single-file vs. batch), and keep these associations fixed. Apologies if I'm overlooking something obvious.

Well, the confusion seems to come from the fact that you believe that there are different validation modes, when there is just the one. There is no distinction between batch validation and single validation when it comes to validation scenario associations. They all use the same set of associations. The only distinction is that from the Project view you can make associations at folder level and all files within that folder inherit the folder association (any existing file associations of files from that folder are removed). But it's also possible to override the association at file level afterwards.

If you use from the Project view Validate > Configure Validation Scenarios you are making associations. If you use Validate > Validate you validate with existing associations.
For transformation scenarios it's actually possible to run a batch transformation without creating a transformation scenario association with the files involved (Transform > Transform with...). There is no batch validation equivalent of this (validate with a different scenario without creating an association). So, maybe this discrepancy caused the confusion?

To clarify how the validation mechanism works, when a file is being validated (it doesn't matter if in batch or single) Oxygen looks for the means to validate the file in the following order (first found is used):
1. It checks if a validation scenario is explicitly associated with the file (This can be set by using Configure Validation Scenarios on the file).
2. It checks if a validation scenario is associated with a folder from its path (This can be set by using Configure Validation Scenarios in Project view).
3. It checks if there is a default validation scenario from the document type, if a document type was detected for the file (Document type > Validation tab).
4. It performs a generic validation. For XML a generic validation checks if a schema is associated within the document or is specified in the Document type > Schema tab and uses that to validate it. If there's no schema detected, it reports an error.

Regards,
Adrian

Hi Adrian,

To clarify how the validation mechanism works, when a file is being validated (it doesn't matter if in batch or single) Oxygen looks for the means to validate the file in the following order (first found is used):
1. It checks if a validation scenario is explicitly associated with the file (This can be set by using Configure Validation Scenarios on the file).
2. It checks if a validation scenario is associated with a folder from its path (This can be set by using Configure Validation Scenarios in Project view).
3. It checks if there is a default validation scenario from the document type, if a document type was detected for the file (Document type > Validation tab).
4. It performs a generic validation. For XML a generic validation checks if a schema is associated within the document or is specified in the Document type > Schema tab and uses that to validate it. If there's no schema detected, it reports an error.

Thanks, that's useful. The problem I guess, is a) that this cascade is a bit unclear, and b) easily (and apparently silently) overridden, making it unsure what validation scenario from this cascade will be applied when issueing a "validate" command. I guess I'll just have to try and remember to always reset the validation scenario for a folder (in Project view) to the project's default scenario, after a batch validation with a different scenario.

I think it could be made more transparent if the "Configure Validation Scenarios" dialog would offer a choice between either:

• a one-off validation scenario just for this validation command ==> this is what I would expect for "Apply Associated"

• a permanent validation scenario for future validation commands (i.e. the current behaviour of "Apply Associated") ==> this is what I would expect for a possible new option "Apply and Store Associated"

Kind regards,

Ron

Hi,

a one-off validation scenario just for this validation command ==> this is what I would expect for "Apply Associated"

I do agree that "Apply Associated" does not make it very obvious that it also saves the association. However, a one-off validation is not available because it can generate a lot of confusion when combined with automatic validation, so it was decided against allowing it. I'll explain...

Validation is performed on-demand, but as you open or edit a document, it can also be automatic (with the associated scenario or detected schema). The automatic validation feature can be disabled, but that's another story. So, by default, if you would run a one-off validation with a scenario/schema you'll get a list of warnings and errors As you try to double click on these to open the documents and investigate and try to fix the errors, you'll trigger the automatic validation which can provide different results (e.g. no errors or a lot more errors).

So in the end, this can be a counter-productive feature for the user, if not decoupled from the automatic validation (document opening and editing). We will probably allow this in the long term, maybe with a different way of presenting the error report.

Regards,
Adrian

Hi Adrian,

Thanks for your elaboration. I fully understand an integrated editor is a complex beast and that UI decisions have way more far-reaching consequences than it seems at first sight.

Validation is performed on-demand, but as you open or edit a document, it can also be automatic (with the associated scenario or detected schema). The automatic validation feature can be disabled, but that's another story. So, by default, if you would run a one-off validation with a scenario/schema you'll get a list of warnings and errors As you try to double click on these to open the documents and investigate and try to fix the errors, you'll trigger the automatic validation which can provide different results (e.g. no errors or a lot more errors).

I see, that's what happens when a "Validate with Schema" command is run on a batch of files (and maybe possible discrepancies between the batch validation and automatic validation when opening the individual files is more intuitive/acceptable for this command). If it would be possible to select multiple schemas for "Validate with Schema", that could provide some way to define "ad-hoc" validation scenarios for batch validation (I notice Oxygen does remember the schema selected for previous runs of the "Validate with Schema" command).

Best,

Ron

Hi,

Yes, "Validate with Schema" from the Project view (batch) is another example of a similar situation. This was implemented a long time ago without giving it much thought, and was left that way. Even though it's a bit more intuitive, we still have received some reports regarding the confusion created when users tried to repair validation errors and triggered automatic validation that cleared those errors.
"Validate with Schema" has a completely different implementation, it does not have the possibilities of a validation scenario. Validating with multiple schemas (multiple validation units) is only possible within a validation scenario.

(I notice Oxygen does remember the schema selected for previous runs of the "Validate with Schema" command).

It only remembers the last schema used in the dialog, there is no "association".

Regards,
Adrian