Oxygen XML Forum

We have a problem with authors using the transformation scenarios set up for them with non-valid XML. After the resulting HTML/JS/CSS files don't work, our team receives bug tickets.

Initial brainstorming included:
1. Force a validation before transformation.
2. Move the transformations out of the scenarios view, make them actions, add them to the toolbar, and make them only available if the current document is valid.
3. Tell authors, "Don't do that."

After brainstorming we hit the software, manuals, and web for answers. We then concluded that our only option was to tell our authors, "Don't do that." Not a very compelling story.

Searching the forums, I came across this thread: http://www.oxygenxml.com/forum/post1635 ... ion#p16350
It was posted in 2005. I haven't seen any updates on the topic since then and can't find any other information concerning the issue. Am I missing something in Oxygen 14.1?

I need this:
1. Automatic validating during authoring. (have it already)
2. Transformation input to allow for a validation scenario. (must have)
3. Transformation output to allow for validation scenario. (nice to have, it trust my own xslt)
4. If the input validation, transformation (for some reason), or the output validation fails, the whole transformation should fail with the appropriate error.

Hello,

So, I guess what you actually want is to prevent the user from starting the transformation, if the input XML is not valid and then notify if the output is not valid.

Regarding 2., if an XML schema is associated with the input XML file, then you already have validation when you transform with Saxon-PE/EE. You can control if the validation should be enforced in the Advanced options (cogwheel icon) from the transformation scenario editing dialog. You can set the option: Validation of the source file to Schema validation ("strict"). Note this validation works only for XML schema(.xsd), not for DTD or anything else.

Regarding 3. and the other topic (from 2010), the user referred to the output of the transformation from the XSLT debugger, which appears in a separate view and does not have validation. The workaround I proposed there and that I also offer you in this case is to enable "Open in Editor" for the output. Once open in the editor, Oxygen will automatically validate it (if a DTD/schema is associated).

There aren't other means to force a validation before running an Oxygen transformation, but there's the automatic validation that is always there to flag the problems. However that does not stop the user from running the transformation on an invalid XML input.

Another approach would be to write and run an ANT or XProc script (within or even outside of Oxygen) that first performs the validation of the input and then the transformation. You could also validate the resulting output. However, this script will not have access to the validation/transformation scenarios or even engines that Oxygen provides.

I have submitted a feature request on our issue tracking tool for validating the input and the output of the transformation. This will be analyzed and if found appropriate, it will be implemented in a future version of Oxygen.

Regards,
Adrian

So, I guess what you actually want is to prevent the user from starting the transformation, if the input XML is not valid and then notify if the output is not valid.

Correct. The users is try out all sorts of funky element combinations that look pretty in the transformed HTML, but that break the semantic XML schema. Then, I'm left to defend our position about data abstraction... The users ignore the invalid errors they receive while editing. To enforce our data modeling policy, I'd like to enforce validation before transformation.

Note this validation works only for XML schema(.xsd), not for DTD or anything else.

And there's the problem. We've outgrown .xsd and DTD. We have been standardized on Relax NG + Schematron 2.0 for over a year now.

Another approach would be to write and run an ANT or XProc script (within or even outside of Oxygen) that first performs the validation of the input and then the transformation.

I thought of doing this. Passing arguments along to the script that would normally be XSLT parameters. It could work, but would be a visual feedback kludge. We may end up having to go this route.

This will be analyzed and if found appropriate, it will be implemented in a future version of Oxygen.

Fair enough. Thank you.