This document was created September 2017 by Andrew Leaver-Fay. The validate_rosetta_script
application is maintained by Brian Kuhlman's lab. Send questions to (bkuhlman@email.unc.edu)
The "entry-point" code for the validate_rosetta_script
application lives in src/protocols/rosetta_scripts/RosettaScriptsParser.cc
, however, it relies on the schemas defined by hundreds of Movers, Filters, ResidueSelectors, TaskOperations, etc that are distributed throughout the code base.
A demo for the use of this application lives in the Rosetta/rosetta_scripts_scripts/testing/validate_all_scripts.py -- this script will run the validate_rosetta_script application against all of the scripts listed in Rosetta/rosetta_scripts_scripts/scripts_to_validate.py
The original rosetta_scripts paper was published in the following paper:
Fleishman, Sarel J., et al. "RosettaScripts: a scripting language interface to the Rosetta macromolecular modeling suite." PloS one 6.6 (2011): e20161.
The purpose of this application is to test an XML script written for the rosetta_scripts application to ensure that it is valid according to Rosetta's internally-generated XML Schema. If the script is valid, then the application will print a brief success message and exit with a 0 exit status -- if not, it will print any error message that had been generated, and exit with a non-zero exit status.
The script loads in the XML file, expanding all xi:include tags that it encounters, and replacing all script-vars variables that it finds. It constructs the schema for rosetta_scripts and validates the input XML file against the schema.
This application does not execute a rosetta script, nor does it ensure that the parse-my-tag functions of the objects defined within the input script would succeed. This application merely verifies that the input script is valid according to the XSD. E.g., you might specify two mututally exclusive attributes for a Mover so that parsing would not succeed, but where schema validation would succeed. This application cannot detect that kind of problem in the input script.
The principle input files for this application are XML files. One XML file may include another XML file using an <xi:include href="filename">
tag.
This allows you to reuse elements in multiple scripts withut duplication.
No other input files should be accessed, as the objects within the XML file are not constructed.
There are two principle command-line arguments to use with rosetta_scripts and rosetta-scripts-like applications (such as this one)
-parser:protocol <xml-filename> The script that will be read and whose tags will be turned into Rosetta objects
-parser:script_vars <ws-sep-varname-equals-value-pairs> The input XML file(s) may contain variables that can then be replaced with other
values from the command line. These variables should be enclosed in double % symbols.
E.g. <SomeTag value="%%myvariable%%"/>. The variable in the previous XML element named
myvariable can be replaced with a particular value, e.g. 10.3 by having the script_vars
flag on the command line: --parser:script_vars myvariable=10.3
You may have as many variables as you would like; each variable should be separated by
whitespace (i.e. the ws-sep part; it is white-space-separated). The variable name an
the value you wish to assign should be separated by an equals sign. Valid variable names
include any alpha-numeric strings and may contain underscores; they should not contain
consecutive percent symbols. Alternatively, you may include the script_vars option multiple
times on the command line, giving a different variable=value pair for each instance.
You can use the -parser:info <tag-name>
option with the rosetta_scripts application to print out XML-schema information
and associated documentation text for a particular Tag with the requested tag-name if you find that one Mover/Filter/etc.
is invalid according to the XSD.
Exits with a brief success message if the input script can be parsed and with a zero exit status; exits with a detailed error message and a non-zero exit status otherwise.
No post-processing