Multiple inheritance for frameworks?

[wschildbach]

I am looking for a way to have more than one frameworks apply to the same source file. Here is my scenario.

I am currently working with OxygenXML 18.1.

We have a framework that operates on our own specialized DITA flavor. It is extended from the standard DITA framework that comes with Oxygen.
We also have a second framework that operates on DITA or our specialization, and provides generic functionality (checking the source against the use of deprecated terms, and suggesting <term/> markup).

I would like to share the second (termchecker) framework as add-on; and would expect that when it is installed, it adds to any functionality that users may already have configured in their own settings. I.e. if they have a plain DITA framework configured, it adds on top of that (as if it was extending the plain DITA framework), if they have our other framework configured (or any other DITA framework) then it adds/extends on top of that.

"Adding" in this context primarily means supplying additional validation (and possibly transformation) scenarios. So I would expect the applicable validation scenarios to be the union of those supplied by all frameworks with matching association rules.

Unfortunately, it does not work this way -- the highest priority framework whose association rules match wins. Exclusively.
Is there a way to have several frameworks apply to the same file?

Thanks
Wolfgang

[wschildbach]

I guess another way to ask this question is whether there is any way to "inject" scenarios into frameworks that I don't control (but without creating extensions for every one of those frameworks).

- Wolfgang

[Radu]

Hi Wolfgang,

As you said, Oxygen uses only the first framework which matches an XML document.
So we don't have such a possibility to merge two or more frameworks to provide an unified editing experience.
An Oxygen plugin can force a set of global options to the application, there is an example here:

https://github.com/oxygenxml/wsaccess-j ... se-options

So a plugin could come with a set of Schematron schemas + with a set of validation scenarios which would use them.
But you also want the validation to work by default when the end user opens the topics, instead of relying on the end user to configure the validation scenarios for the topics. And I don't think this can be done from a plugin.
A plugin can also add a Validation Problems Filter ro.sync.exml.workspace.api.editor.WSEditor.addValidationProblemsFilter(ValidationProblemsFilter) so it could provide extra errors to report on an opened document or filter out existing errors. But we do not have API to apply a validation scenario from a plugin.

Another approach:

The base DITA framework already has a "DITA" validation scenario and this scenario has a validation stage which applies Schematron-based validation with the Schematron located in ${framework}/resources/dita-1.2-for-xslt2-mandatory.sch.
You could provide a framework which contributes its own XML catalog in the list of catalogs which redirects the reference to the mandatory Schematron so that the Schematron file in the framework is used instead:

Code: Select all

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

    <uriSuffix uriSuffix="/resources/dita-1.2-for-xslt2-mandatory.sch" uri="my-custom-sch-from-my-custom-framework.sch"/>

</catalog>

Thing is that although Oxygen uses only one framework when editing the XML document, the XML catalogs are gathered from all contributed frameworks and used in common.
So your framework could have no association rules and just provide this XML catalog which redirects the reference to the mandatory Schematron file so that the custom Schematron from your framework is used instead.

Regards,
Radu

[wschildbach]

Thanks Radu for your long answer. I'll take a look at the options.

Specifically the last one (catalog override) looks interesting. I guess the challenge would be how to not lose the original dita schematron checks while overriding them in the catalog. That could be tricky.

I have one more short follow-on question just to make sure I am not doing anything stupid, but I'll post that into a new thread. Thanks again!

- Wolfgang

[Radu]

Hi Wolfgang,

The original DITA mandatory Schematron checks are not many and also not that necessary, so not much to lose.

Regards,
Radu