Output of external XSLT processors

[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

[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

[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

[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

[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>

[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.

[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

[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.