Page 1 of 1

Output of external XSLT processors

Posted: Fri Feb 20, 2026 11:09 am
by anhil
Hello all,

what is the expected output of an external XSL processor? When the processor prints "Hello!" on STDOUT, oxygen gets the following:

Code: Select all

System ID: /Users/patrick/work/software/bag/goxslt/examples/catalog.xsl
Scenario: catalog
XSL file: /Users/patrick/work/software/bag/goxslt/examples/catalog.xsl
XML file: /Users/patrick/work/software/bag/goxslt/examples/catalog.xml
Engine name: goxslt
Severity: warning
Description: Hello!

Is there a way to distinguish between different severity levels?

Thank you!
Patrick

Re: Output of external XSLT processors

Posted: Wed Feb 25, 2026 12:24 pm
by teo
Hello Patrick,

When using a custom external XSLT processor, Oxygen captures the process output (STDOUT and STDERR) and tries to interpret it.
So, the severity is inferred automatically from the processor output.
If the output does not follow a recognized error message format (for example including file name, line number, and severity), Oxygen will typically display it as a warning by default.
There is no automatic distinction between severity levels unless the output matches a recognized format.

Regards,
Teo

Re: Output of external XSLT processors

Posted: Wed Feb 25, 2026 3:30 pm
by anhil
What exactly is a "a recognized format"? Is there any documentation on it? The help page does not mention it: https://www.oxygenxml.com/doc/versions/ ... gines.html

Re: Output of external XSLT processors

Posted: Wed Feb 25, 2026 6:41 pm
by teo
Follow the link below for more details on the output format for a custom engine so that errors appear in the results view:
https://www.oxygenxml.com/doc/versions/ ... ngine.html

Re: Output of external XSLT processors

Posted: Thu Feb 26, 2026 4:23 pm
by anhil
Is there a way to recognise messages? I see the types F|E|W, is M also recognised? For example for the output of <xsl:message>

Re: Output of external XSLT processors

Posted: Thu Feb 26, 2026 7:39 pm
by teo
I noticed your great interest in integrating your custom transformer with Oxygen.
That's why I registered an internal task for a detailed analysis of the aspects you brought up.
I also did this because, regarding those 'recognized output formats' discussed on this thread, there may be some limitations in the case of custom transformation processors versus custom validation processors.
That is, I think that in the case of transformers, the messages issued are 'assimilated' by default as warnings by Oxygen, otherwise the transformation is aborted.
These are just assumptions for now, I will have to check in the code and test these aspects, which is more difficult to do without having access to your transformer and the related implementation.
Unfortunately, we are in a very busy period, preparing for the launch of the new version of Oxygen in 2 weeks.
But I promise that I will take the time to investigate the issues you raised, and I will come back with clarifying explanations in the second half of next week.

Re: Output of external XSLT processors

Posted: Thu Feb 26, 2026 10:24 pm
by anhil
Thank you very much for taking your time, Teodor. I will happily come back to this after the release!

I am sure that this is only something "nice to have" and nothing critical, so I'd be happy to share my thoughts, but it would be okay for me if this is a "won't change" feature.

Patrick

Re: Output of external XSLT processors

Posted: Wed Mar 04, 2026 4:36 pm
by teo
As promised, I analyzed in more detail our code related to the implementation of external transformers.
And I found that indeed the messages issued are explicitly 'assimilated' by default as warnings in the respective class.
The reason being precisely to avoid aborting the transformation in certain scenarios.
However, I think we could intervene in such a way as to differentiate between the types of messages issued, but it must be rigorously tested using a more complex and realistic "setup" than the one I used in the analysis.

We discussed all these aspects within our team and decided to postpone the interventions for now.
As previously mentioned, there is already a task registered for the issue in question.
It will be addressed in the near future, so that a fix/improvement will be available in version 29 of the Oxygen suite.