B. Parameters for Controlling XVRL Generation

The following parameters should be understood by XVRL report generators when converting underlying validation reports, for example, from SVRL or from the XProc error vocabulary, c:errors etc.

xvrl:default-severity

When no severity is associated with a source vocabulary element that is mapped to detection, this property can be specified in order to assign a default severity to any of these source vocabulary constructs. It can be argued that the XProc error vocabulary, c:error, already conveys the severity level error. The view that this specification takes is to regard these messages as generic findings of severity “error”, but that the xvrl:default-severity may be given to override this.

Implementations are free to provide other parameters, in a different namespace, that permit a more detailed mapping, for example from error code to severity.

xvrl:serialization-format

Anticipates future alternative serialization If no value is given, xml is assumed. Other possible values may be, but are not limited to, json, rdf/xml, turtle.

xvrl:language

A space separated list of language abbreviations, typically according to ISO 639-1. The preferred language is given first, followed by fallback languages. The result is that localized elements within a detection will be reduced to messages, categories, or summaries in the preferred language. Example: de en instructs the XVRL generator to include German messages only and to use an English message when no German message is present. If no language matches for a given localizable element in a detection context, a corresponding element with the same attributes, but with no xml:lang attribute, should be included. Localizable elements with an xml:lang attribute that is not listed in this property should be ignored.

xvrl:map-to-severity

This parameter contains space-separated QNames that correspond to elements or attributes of an underlying reporting language, in particular SVRL attributes. A value of flag role instructs an SVRL to XVRL converter to preferentially map the SVRL flag attribute to the XVRL severity attribute. If it is not present or its value cannot be mapped, it should try to map the SVRL role value to XVRL’s severity.

The following attribute values are considered mappable, after folding the source value to lower case: “information”, “informational” map to “info”; “warn” maps to “warning”; “fatal” maps to ”fatal-error”. A conversion tool may consider other variants, including translations that correspond to the natural language of the corresponding error message, for mapping.

If the content of an (for example) SVRL attribute cannot be mapped, it should be attached to the corresponding XVRL detection either as a category or as a namespaced attribute (that is, role="foo" in SVRL may become svrl:role="foo" in XVRL, with xmlns:svrl="http://purl.oclc.org/dsdl/svrl").

xvrl:xpath-notation

This parameter controls how XPath attributes given in location elements should be structured. Possible values are “Q”, “namespace-uri“, and “name”.

Example: The path /TEI/text[1] in the namespace http://www.tei-c.org/ns/1.0 will be represented in these notations as follows:

Q

/Q{http://www.tei-c.org/ns/1.0}TEI/Q{http://www.tei-c.org/ns/1.0}text[1]

namespace-uri

/*:TEI[namespace-uri()='http://www.tei-c.org/ns/1.0']/*:text[namespace-uri()='http://www.tei-c.org/ns/1.0'][1]

This corresponds to the parameter setting full-path-notation=1 in the SVRL output of the Schematron skeleton implementation.

name

/tei:TEI/tei:text[1]

This corresponds to the parameter setting full-path-notation=2 in the SVRL output of the Schematron skeleton implementation. It takes namespace prefix declarations from the source document and it needs to copy these declarations to an appropriate location in the resulting XVRL document.

If the XVRL attribute xpath-default-namespace is present on an ancestor element, the namespace URI given in this attribute on the closest ancestor should be used to omit this namespace from the resulting XPath. If xpath-default-uri="http://www.tei-c.org/ns/1.0" is in force in a given context, the paths in any of the three notations should reduce to /TEI/text[1].

If an XVRL-generating application is unable to generate the preferred notation, any XPath notation that it can produce is acceptable.