Alternate versions of the test vocabulary definition exist in Turtle and JSON-LD.
A CompactTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
A ExpandTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
A FlattenTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
A FrameTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
A FromRDFTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
An HtmlTest modifies either a PositiveEvaluationTest or NegativeEvaluationTest indicating that the source is of type text/html, which requires optional HTML script extraction support.
An HttpTest modifies either a PositiveEvaluationTest or NegativeEvaluationTest.
A Negative Evaluation test is successful when the result of processing the input file specified as mf:action (aliased as "input" in test manifest) results in the error identified by the literal value of mf:result (aliased as "expectErrorCode" in test manifest). The specifics of invoking test, including the interpretation of options (:option) and other input files are specified through another class. See the README for more details on running tests.
A type of test specifically for syntax testing. Syntax tests are not required to have an associated result, only an action. Negative syntax tests are tests of which the result should be a parser error.
A Positive Evaluation test is successful when the result of processing the input file specified as mf:action (aliased as "input" in test manifest) exactly matches the output file specified as mf:result (aliased as "expect" in test manifest) using the comparison defined in another class. The specifics of invoking test, including the interpretation of options (:option) and other input files are specified through another class.
A type of test specifically for syntax testing. Syntax tests are not required to have an associated result, only an action.
Options passed to the test runner to affect invocation of the appropriate API method.
All JSON-LD tests have an input file referenced using mf:action (aliased as "input" in test manifest). Positive and Negative Evaluation Tests also have a result file referenced using mf:result (aliased as "expect" and "expectErrorCode" for respectively Positive and Negative Evaluation Tests in test manifest). Other tests may take different inputs and options as defined for each test class. Tests should be run with the processingMode option set to "json-ld-1.1", unless specified explicitly as a test option.
A ToRDFTest modifies either a PositiveEvaluationTest, NegativeEvaluationTest, PositiveSyntaxTest or NegativeSyntaxTest.
An HTTP Accept header.
An HTTP Link header to be added to the result of requesting the input file.
The HTTP status code that must be returned when the input file is requested. This is typically used along with the redirectTo property.
The base IRI to use when expanding or compacting the document. If set, this overrides the input document's IRI.
If set to true, the JSON-LD processor replaces arrays with just one element with that element during compaction. If set to false, all arrays will remain arrays even if they have just one element.
If set to false, the JSON-LD processor will not attempt to compact using document-relative IRIs.
The HTTP Content-Type used for the input file, in case it is a non-registered type.
A context that is used for transforming the input document.
A context that is used to initialize the active context when expanding a document.
Whether to extract all script elements from HTML, or just the first encountered.
Secondary input file
A frame that is used for transforming the input document.
Indicates that this is or is not a test of a normative requirement. Tests without this option are treated as being normative.
Options affecting processing
If set to "json-ld-1.1", the JSON-LD processor must produce exactly the same results as the algorithms defined in this specification. If set to another value, the JSON-LD processor is allowed to extend or modify the algorithms defined in this specification to enable application-specific optimizations. The definition of such optimizations is beyond the scope of this specification and thus not defined. Consequently, different implementations may implement different optimizations. Developers must not define modes beginning with json-ld as they are reserved for future versions of this specification.
A particular processor feature that may be supported by some implementations.
Unless the produce generalized RDF flag is set to true, RDF triples containing a blank node predicate are excluded from output.
The location of a URL for redirection. A request made of the input file must be redirected to the designated URL.
Indicates the JSON-LD version to which the test applies, rather than the specific processing mode. Values are "json-ld-1.0", and "json-ld-1.1". If not set, the test is presumed to be valid for all versions of JSON-LD. In cases where results differ between spec versions for the same test, the test will have both a "1.0" and "1.1" version, for example.
Requires the use of JSON Canonicalization Scheme when generating RDF literals from JSON literal values.
If the use rdf type flag is set to true, statements with an rdf:type predicate will not use @type, but will be transformed as a normal property.
If the use native types flag is set to true, RDF literals with a datatype IRI that equal xsd:integer or xsd:double are converted to a JSON numbers and RDF literals with a datatype IRI that equals xsd:boolean are converted to true or false based on their lexical form.
Optional test to serialize text direction using compound-literal
Test generates Generalized RDF
Optional test to serialize text direction using i18n-datatype