CODEWITHSUNDEEP
javaxmlxsdtags
javaPlease42
javaPlease42

Reputation: 4963

What is the maximum integer for maxOccurs in a XSD XML Schema?

Is "2147483647" the maximum value that maxOccurs can handle? What is the maximum value that maxOccurs can handle? Setting a maxOccurs value to unbounded can lead to resources exhaustion and ultimately a denial of service

Here an example XSD with the maxOccurs set to what I think is the Maximum value that maxOccurs can handle please verify:

mySchema.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="family">
    <xs:complexType>
        <xs:choice maxOccurs="unbounded">
            <xs:element name="person" maxOccurs="2147483647">
                <xs:complexType>
                    <xs:sequence>
                        <xs:element name="name" type="xs:string"/>
                        <xs:element name="firstname" type="xs:string"/>
                        <xs:element name="age" type="xs:int"/>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
            <xs:element name="address" type="xs:string" minOccurs="1"/> 
        </xs:choice>
    </xs:complexType>
</xs:element>

Upvotes: 1

Views: 6042

Answers (2)

C. M. Sperberg-McQueen
C. M. Sperberg-McQueen

Reputation: 25034

As Petru Gardea has already noted, 2147483647 is not the highest legal value for maxOccurs for the simple reason that there is no highest legal value. The schema for schema documents in the XSD spec declares maxOccurs with a union type of xsd:nonNegativeInteger and the token 'unbounded', and xsd:nonNegativeInteger is ultimately a subtype of xsd:decimal. The rules on minimum implementation limits require that all implementations support all decimal values which can be written with sixteen significant decimal digits. So the largest value which is guaranteed to be accepted by all conforming XSD implementations is, I guess, 9999999999999999.

Specifying a numeric value for maxOccurs requires that the validator keep track of exactly how many elements it has seen, which makes for a larger finite state automaton (and is thus counterproductive if your goal is to limit resource usage).

A more reliable method of preventing resource exhaustion would be to run the validator in a process which has time limits and/or memory limits. Pretty much every operating system written in the last 50 years has the ability to impose such limits, and some XML parsers (such as rxp) have run-time options for the same purpose. Is there a reason you want to place your resource limits in the schema instead of using operating-system limits on the parsing process?

Upvotes: 1

Petru Gardea
Petru Gardea

Reputation: 21638

From the spec, the answer is: no limit. Below are snippets from the spec (links to XSD 1.0):

maxOccurs = (nonNegativeInteger | unbounded) : 1

For nonNegativeInteger, "The ·value space· of nonNegativeInteger is the infinite set {0,1,2,...}. "

Since no limit doesn't practically exists, each implementation sets its own...

Whether is "some Microsoft library" as someone was commenting earlier, or Java as it seems in your case, or an XML appliance, the limits may be clearly defined (as in Microsoft's case) or funky to understand, or managed externally through policies associated with your XML processor (most notably present in XML appliances).

For e.g., the maximum value that Xerces may return for a numeric maxOccurs is limited by what int means in Java, which is 2^31-1. If you put a 2^31 as maxOccurs in your XSD, some may say that Xerces will not behave appropriately... I believe it flips to unbounded...

I know for sure that setting high numbers to maxOccurs, in an attempt to prevent the DoS, may in fact have the opposite effect (have a look at this post)...

Upvotes: 3

Related Questions