Hello, The validation action executes the command line defined for the "Other" schema type instead of the NVDL or SCH type. It is a bug and we will fix it in the next version of Oxygen. Please specify the full path of the schema in the command line for "Other" schema types until we fix the problem. In this case you have to create a different scenario for each different schema path. Regards, Sorin Stefan Krause wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Sorin,
I tracked this a little bit down. It works fine if the "Schema type" is XML Schema, DTD, RNG, or RNC:
SystemID: D:\temp\test.xml Main validation file: D:\temp\test.xml Engine name: XSLT-Validierung Severity: info Description: Executing: java -jar "D:\tools\saxon\saxon_9.1\saxon9.jar" - -s:"file:/D:/temp/test.xml" -xsl:"file:/D:/docs/NurText2.xsl" - -o:D:\temp\trash.xml -l:on Err.LinkedOutput=yes ArchiveType=RNC
It does not work if the "Schema type" is NVDL or Schematron. In this cases, Oxygen invokes the command line which I had defined for "other" without expanding ${ds}:
SystemID: D:\temp\test.xml Main validation file: D:\temp\test.xml Engine name: XSLT-Validierung Severity: info Description: Executing: java -jar "D:\tools\saxon\saxon_9.1\saxon9.jar" - -s:"file:/D:/temp/test.xml" -xsl:${ds} -o:D:\temp\trash.xml -l:on Err.LinkedOutput=yes ArchiveType=OTHER
The parameter of the custom validation engines are:
name: XSLT-Validierung executable path: java working directory: . command line XSD: -jar "D:\tools\saxon\saxon_9.1\saxon9.jar" -s:"${currentFileURL}" - -xsl:"${ds}" -o:D:\temp\trash.xml -l:on Err.LinkedOutput=yes ArchiveType=XSD RNG: -jar "D:\tools\saxon\saxon_9.1\saxon9.jar" -s:"${currentFileURL}" - -xsl:"${ds}" -o:D:\temp\trash.xml -l:on Err.LinkedOutput=yes ArchiveType=RNG [...] Other: -jar "D:\tools\saxon\saxon_9.1\saxon9.jar" -s:"${currentFileURL}" - -xsl:"${ds}" -o:D:\temp\trash.xml -l:on Err.LinkedOutput=yes ArchiveType=OTHER
If you are curious: the stylesheet sends messages in Oxygens Linked Output Format. It would be nice to have linked messages within the regular XSLT message panel.
Best regards,
Stefan
Am 01.07.2011 13:43, schrieb Sorin Ristache:
Yes, both variables ${ds} and ${dsu} are expanded to the location of the schema when you run the validation action and the command line of the custom validation engine is executed. This is true for both the detected schema option (the radio button "Use detected schema") and the custom schema one (the radio button "Use custom schema") of the validation scenario.
You don't have to create a different validation engine in Options -> Preferences -> Editor -> Custom Validation Engines. You have to create a different validation scenario using the Configure Validation Scenario action only if you want to validate against a custom schema with a different URL. The same validation engine can be set in any validation scenario that you want.
Did you set ${ds}/${dsu} in the command line of the custom validation engine? Please note that you should use either the ${ds} variable or the ${dsu} one, not both variables in the same command line. ${ds} has the form of a full file path (not a relative file path) and ${dsu} has the form of a URL which means ${ds}/${dsu} makes no sense. The editor variables are explained both in the popup menu that is displayed when you insert the variable and in the User Manual:
http://www.oxygenxml.com/doc/ug-oxygen/topics/preferences-editor-custom-vali...
If you have only ${ds} or ${dsu} in the command line please send the output of the validation action that is displayed in the Info view at the bottom of the Oxygen window. Also send the parameters of the custom validation engine (name, executable path, command line, etc).
Regards, Sorin
[...] If yes the variable ${ds} or ${dsu} from the command line of the custom validator should be replaced with the file path or URL of the schema from the scenario. [...]
Do you mean, that ${ds}/${dsu} should be expanded by Oxygen to the schema url (and in my case it just does not), or that I have to create a distinct custom validation engine for every custom schema I want to use?
In the latter case, it would be nice feature to map the custom schema to ${ds}/${dsu}.
Thanks
Stefan