
This parses the argument, which is expected to be an XML
fragment (possibly with syntax errors, violations of validity conditions etc.)
and returns a human-readable list of errors as a string.
 DTD validation may be performed during any reading of XML
source in functions xml_tree, xml_persistent or xper_doc, so that an application may
check XML source on the fly; severe constraint violations in source XML will
be signalled as SQL runtime errors. Configuration string is a sequence of pairs
parameter=value, delimited by spaces. No errors are reported if a parameter
is specified twice, in which case the last specified value will be used.   The only exception is the @Validation@ parameter which
sets typical values for all parameters. Both names and values are case-insensitive. Many parameters are used to specify the importance of a
particular error. For a particular application some validity constraints may be much more
important than others. Because less than perfectly valid XML is common in practice it
is important to configure the validator to report only those errors which  are relevant to the application.  Using configuration parameters, one may specify "importance levels"
for every group of problems. There are 5 "importance levels":
Some parameters are just switches, with only two values available: @ENABLE@ and @DISABLE@.
AttrCompletion (ENABLE/DISABLE, default is DISABLE)
is useful when DTD validator is invoked from XML parser.
When enabled, the XML document built will contain default values of @IMPLIED@ attributes as if they present in source text.
It may be useful if application should perform free-text search on all attribute values including defaults or if XML should be converted in form suitable for external non-validating XML processor or if given XML data should be stored later as part of composite document and composite document will have another DTD with other default values.
AttrMisFormat (FATAL/ERROR/WARNING/IGNORE/DISABLE) describes how to report errors in syntax of attributes@ values.
AttrUnknown (FATAL/ERROR/WARNING/IGNORE/DISABLE) describes how to report attributes whose names are not listed in DTD.
BadRecursion (FATAL/ERROR/WARNING/IGNORE/DISABLE) describes how to report circular references, when replacement text of an entity contains reference to this entity again, either directly (e.g. @<!ENTITY bad "some &bad; replacement">) or through other entities (e.g. @<!ENTITY a "&b;"> @<!ENTITY b "&a;">).
BuildStandalone (ENABLE/DISABLE, default is DISABLE)
when enabled, replacement texts of external entities will be inserted instead of references to these entities, thus all data from a composite document will be gathered together into one large XML.
This is useful for checking the element content model of the whole document without breaks on references or if parsed XML will be passed to external application as standalone document.
Fsa (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report violations of specified element-content model.
Virtuoso@s DTD validator contains a finite state automaton which can detect the first error in the content of some element, but remaining errors in the same element become "obscured" by the first one and will not be reported.
Moreover, if element-content model is not SGML-compatible, some errors may remain undiscovered: it is possible to write a complex rule, so ambiguous that full check of all its interpretations will take prohibitively much time and memory.
The validator will simplify such rules to make check faster, thus some errors will not be reported.
FsaBadWs (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report the most popular violation of element-content model specified by DTD:
the use of whitespace characters in positions where only elements are allowed, not PCDATA.
It usually happens when XML is indented for readability.
You may wish to specify @FsaBadWs=IGNORE@ to eliminate redundant messages about this violation.
Note that if you will specify @FsaBadWs=DISABLE@ then you will disable the check of illegal PCDATA tokens for this particular case,
so common rule for @Fsa@ violations will be applied and you will see messages.
FsaSgml (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report violations of SGML compatibility in element-content model.
Some complex DTD rules for elements are not supported by SGML processors and the validator may report the use of such rules.
GeRedef (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report redundant definitions of generic entities.
There redefinitions are errors in SGML but they may be ignored in XML processing (the first definition will be used and others will be ignored).
IdDuplicates (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report non-unique values of ID attributes.
It is a data integrity error, because IDs are usually parts of some primary keys, and are expected to be unique.
IdrefIntegrity (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report "dangling references".
Any value of IDREF attribute and any name from value of IDREFS attribute should appear in the same XML document as value of some ID attribute.
You can think that ID attribute specifies an hyperlink anchor and IDREF is a hyperlink, so it@s a data integrity error if hyperlink points to unknown location.
Include (FATAL/ERROR/WARNING/IGNORE/DISABLE)
configures reading of external sub-documents into "main" document you validate (and maybe load in database).
If @DISABLE@, no additional documents will be read, otherwise external parameter-entities, external generic-entities and external DTD will be located, using their SYSTEM names.
External documents may reside in file system, in database or in the Web. Absolute SYSTEM names (of form @protocol://server/resource@) will be used without any modifications, relative SYSTEM names should be "resolved", i.e. converted to absolute by adding prefix from base_uri argument of SQL function.
MaxErrors (integer from 1 to 10000, default is 25)
specifies how many errors may be logged before "Too many error messages" fatal error will be reported.
MaxWarnings (integer from 0 to 10000, default is 100)
specifies how many warnings may be logged before "Too many warning messages" event will stop their logging.
NamesUnknown (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report if document contains element names which are not declared in DTD.
They may be typos in element names or signal that DTD is incomplete or obsolete.
In addition, unknown names may be reported as element-content model violations.
NamesUnordered (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report element names not declared before use in DTD.
Proper order ("declare element name before use it") is important solely for compatibility with SGML standard.
NamesUnresolved (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report if element name used in DTD is not declared at all.
It may occur if DTD is incomplete or if some declaration are in ignored conditional sections.
Unresolved names cause no data integrity errors while remain unused in data section of the XML document, NamesUnknown parameter defines what happens if they@re actually used.
PeRedef (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report redundant definitions of parameter entities.
Similarly to redefinitions of generic entities, there redefinitions are errors in SGML but they may be ignored in XML processing (the first definition will be used and others will be ignored).
Sgml (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report violations of SGML compatibility.
In fact, not all such violations are detected by current version of Virtuoso Server, because known SGML readers are insensitive to some sorts of violations.
TooManyWarns (FATAL/ERROR/WARNING/IGNORE/DISABLE)
describes how to report "Too many warning messages" event.
While "Too many errors" is fatal error and terminates XML processing, "Too many warning messages" may have arbitrary "importance levels".
TraceLoading (ENABLE/DISABLE, default is DISABLE)
If enabled, the validator will log every reading of any resource, for easier tracking of URI resolving problems.
It@s possible that some readings of sub-documents will not be reported: there@s a limit for number of records in the log returned by the validator.
In addition, sub-documents may be cached inside validator, so only first references to some sub-document will require reading procedure.
Validation (SGML/RIGOROUS/QUICK/DISABLE, default is DISABLE)
loads one of four "preset configurations". It must be the first parameter in configuration string, if used.
DISABLE means "do not check for any type of error", QUICK is to check only for violation of "local" validity constraints, with disabled FsaBadWs, IdDuplicates and IdrefIntegrity, RIGOROUS enables these three groups, too, SGML enables all checks including all checks for SGML compatibility.
VcData (ENABLE/DISABLE, default is DISABLE)
describes how to report violations of generic validity constraints in data section of XML document.
If constraint is not configured by other parameters listed here, it will be configured by these parameter (or by VcDtd if relates to the text of DTD section).
VcDtd (ENABLE/DISABLE, default is DISABLE)
describes how to report violations of generic validity constraints in DTD section of XML document.
If constrain is not configured by other parameters listed here, it will be configured by these parameter (or by VcData if relates to the text of data section).