Multiple inheritance for frameworks?
Post here questions and problems related to oXygen frameworks/document types.
-
- Posts: 4
- Joined: Thu Feb 14, 2019 11:30 am
Multiple inheritance for frameworks?
Post by 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
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
-
- Posts: 4
- Joined: Thu Feb 14, 2019 11:30 am
Re: Multiple inheritance for frameworks?
Post by 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
- Wolfgang
Re: Multiple inheritance for frameworks?
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:
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
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>
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
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
<oXygen/> XML Editor
http://www.oxygenxml.com
-
- Posts: 4
- Joined: Thu Feb 14, 2019 11:30 am
Re: Multiple inheritance for frameworks?
Post by 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
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
Re: Multiple inheritance for frameworks?
Hi Wolfgang,
The original DITA mandatory Schematron checks are not many and also not that necessary, so not much to lose.
Regards,
Radu
The original DITA mandatory Schematron checks are not many and also not that necessary, so not much to lose.
Regards,
Radu
Radu Coravu
<oXygen/> XML Editor
http://www.oxygenxml.com
<oXygen/> XML Editor
http://www.oxygenxml.com
Return to “SDK-API, Frameworks - Document Types”
Jump to
- Oxygen XML Editor/Author/Developer
- ↳ Feature Request
- ↳ Common Problems
- ↳ DITA (Editing and Publishing DITA Content)
- ↳ SDK-API, Frameworks - Document Types
- ↳ DocBook
- ↳ TEI
- ↳ XHTML
- ↳ Other Issues
- Oxygen XML Web Author
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Content Fusion
- ↳ Feature Request
- ↳ Common Problems
- Oxygen JSON Editor
- ↳ Feature Request
- ↳ Common Problems
- Oxygen PDF Chemistry
- ↳ Feature Request
- ↳ Common Problems
- Oxygen Feedback
- ↳ Feature Request
- ↳ Common Problems
- Oxygen XML WebHelp
- ↳ Feature Request
- ↳ Common Problems
- XML
- ↳ General XML Questions
- ↳ XSLT and FOP
- ↳ XML Schemas
- ↳ XQuery
- NVDL
- ↳ General NVDL Issues
- ↳ oNVDL Related Issues
- XML Services Market
- ↳ Offer a Service