<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
<head>
<this-is section="schema-processing" page="min-and-maxoccurs" subpage=""/>
<!--
Generated at 2011-12-09T20:47:22.916Z--><title>Saxonica: XSLT and XQuery Processing: Handling minOccurs and maxOccurs</title>
<meta name="coverage" content="Worldwide"/>
<meta name="copyright" content="Copyright Saxonica Ltd"/>
<meta name="title"
content="Saxonica: XSLT and XQuery Processing: Handling minOccurs and maxOccurs"/>
<meta name="robots" content="noindex,nofollow"/>
<link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
</head>
<body class="main">
<h1>Handling minOccurs and maxOccurs</h1>
<p>Prior to release 9.1, Saxon used the validation algorithm described in
<a href="http://www.ltg.ed.ac.uk/~ht/XML_Europe_2003.html" class="bodylink">Thompson and Tobin 2003</a>.
This algorithm can be very inefficient when large bounded values of minOccurs and maxOccurs are used
in a content model; indeed, it can be so inefficient that the finite state machine is too large to fit in
memory, and an OutOfMemory exception occurs.</p>
<p>Since Saxon 9.1, many common cases of minOccurs and maxOccurs are handled using a finite state machine
that makes use of counters at run-time. This eliminates the need to have one state in the machine for each
possible number of occurrences of the repeating item. Instead, counters are maintained at run-time and
compared against the minOccurs and maxOccurs values.</p>
<p>This technique is used under the following circumstances:</p>
<ul>
<li content="para">
<p>Either minOccurs > 1, or maxOccurs > 1 (and is not unbounded), or both</p>
</li>
<li content="para">
<p>The minOccurs/maxOccurs values must be defined on an element (xs:element) or wildcard (xs:any) particle</p>
</li>
<li content="para">
<p>If the repeating particle is <i>vulnerable</i>, then it must not be part of a model group that is itself
repeatable. A particle is vulnerable if it is part of a choice group, or if it is part of a sequence group in which all
the other particles are optional or emptiable, except in the case where minOccurs is equal to maxOccurs. The reason
for this restriction is that in such situations there are two nested repetitions, and it is ambiguous whether a new instance of the repeating term should
be treated as a repetition at the inner level or at the outer level.</p>
</li>
</ul>
<p>In cases where counters cannot be used, Saxon will still attempt to compile a finite state machine, but will use
configuration-defined limits on minOccurs and maxOccurs to approximate the values requested. If the values used in the schema exceed these limits, Saxon will therefore
approximate by generate a schema that does not strictly enforce the specified minOccurs and maxOccurs.
The default limits are 100 and 250 respectively. Different limits can be set on the command line or via the
Java API on the <code>Configuration</code> object. Note however that when several nested repeating groups are
defined it is still possible for out-of-memory conditions to occur, even with quite modest values of minOccurs
and maxOccurs.</p>
<table width="100%">
<tr>
<td>
<p align="right"><a class="nav" href="extensions11.xml">Next</a></p>
</td>
</tr>
</table>
</body>
</html>
