In some respects, this generated code approach is more straightforward to develop, not least because its tangible output is code which can itself then be debugged.

Each pattern, rule and assertion generates a function (in the local namespace), with evaluation context and local variable scope more simply managed at the function level.

The processing of rules is again handled by tail recursion, but this time the function consumes a sequence of function items, for variation:

declare function local:rules($rules as function(*)*)
as element()*
{
if(empty($rules))
  then ()
  else
    let $result := head($rules)()
    return if($result)
    then $result
    else local:rules(tail($rules))    
};

There is no need to pass the instance document to each function representing a rule, since it is passed in as an external variable to the module. Where subordinate documents are present due to pattern/@documents (see the section called “The documents attribute”), an alternate version of this function is also generated with the signature declare function local:rules($rules as function(*)*, $doc as document-node()*).

When it comes to serializing the compiled schema, since most of the generated functions can return some SVRL markup, for simplicity a sequence of strings and elements is passed to serialize(), with the custom basex serialization method specified.

	Note
	The compiled schema places variables for internal use in the XQS namespace, to avoid clashes with variable names in the source schema. For this reason, it is inadvisable to declare the XQS namespace (http://www.andrewsales.com/ns/xqs) in a schema to be compiled by XQS.