XSD: What is the difference between xs:integer and xs:int?

Question

I have started to create XSD and found in couple of examples for xs:integer and xs:int.

What is the difference between xs:integer and xs:int? When I should use xs:integer? When I should use xs:int?

Bachelorism

Answer 1

The difference is the following: xs:int is a signed 32-bit integer. xs:integer is an integer unbounded value. See for details https://web.archive.org/web/20151117073716/http://www.w3schools.com/schema/schema_dtypes_numeric.asp For example, XJC (Java) generates Integer for xs:int and BigInteger for xs:integer.

The bottom line: use xs:int if you want to work cross platforms and be sure that your numbers will pass without a problem. If you want bigger numbers – use xs:long instead of xs:integer (it will be generated to Long).

Bachelorism

Saxon 9 HE (Home Edition) support only 'xs:integer, but not xs:int` or xs:long. – Ingrowth

w3cshools isn't authoritative. Why not reference the proper definitions? w3.org/2001/XMLSchema.xsd states that integer is bound to +/-9223372036854775808, for example. Also, cross platform is nothing to do with the (compliant) xml. – Harlanharland

@Nishi, sounds like Saxon 9 HE isn't conformant. Reading the saxon.sourceforge.net page it seems that only the EE version is conformant. – Harlanharland

@PaulHargreaves, Saxon 9 HE is (as far as I know) a fully conformant XSLT processor: xs:int is not in the set of types a basic XSLT processor is required to support. If you mean it's not a conforming XSD processor, this is true but misleading: it's not an XSD processor at all. – Minuteman

@C.M.Sperberg-McQueen, you're correct - "HE" claims to be basic support but then also throws in a few other bits and bobs as well. Basic support doesn't have schema support and hence no support for int/long etc. Confusing :-) – Harlanharland

@PaulHargreaves, your comment about +/-9223372036854775808 being the maximum of "xs:integer" is wrong : the XMLSchema.xsd defines that a "xs:long" is a restriction of "xs:integer" to +/-9223372036854775808 – Blanketing

In my opinion, in most cases, xs:integer should be used. I think that using xs:int only should be used for compatibility reasons. – Sonorant

Answer 2

The xs:integer type is a restriction of xs:decimal, with the fractionDigits facet set to zero and with a lexical space which forbids the decimal point and trailing zeroes which would otherwise be legal. It has no minimum or maximum value, though implementations running in machines of finite size are not required to be able to accept arbitrarily large or small values. (They are required to support values with 16 decimal digits.)

The xs:int type is a restriction of xs:long, with the maxInclusive facet set to 2147483647 and the minInclusive facet to -2147483648. (As you can see, it will fit conveniently into a two-complement 32-bit signed-integer field; xs:long fits in a 64-bit signed-integer field.)

The usual rule is: use the one that matches what you want to say. If the constraint on an element or attribute is that its value must be an integer, xs:integer says that concisely. If the constraint is that the value must be an integer that can be expressed with at most 32 bits in twos-complement representation, use xs:int. (A secondary but sometimes important concern is whether your tool chain works better with one than with the other. For data that will live longer than your tool chain, it's wise to listen to the data first; for data that exists solely to feed the tool chain, and which will be of no interest if you change your tool chain, there's no reason not to listen to the tool chain.)

Minuteman

You: implementations running in machines of finite size are not required to [...] Does the standard have a requirement that implementations running on infinite machines (like Turing machines and stuff) should accept and properly represent the full range? :-) That would be cool, because the universe, with the laws of physics as they are currently known, does not admit such machines. – Paranoid

No, the specification does not have special rules for implementations running on infinite machines; all implementations are allowed to benefit from the rules governing partial implementation of the infinite datatypes. – Minuteman

Answer 3

I would just add a note of pedantry that may be important to some people: it's not correct to say that xs:int "is" a signed 32-bit integer. That form of words implies an implementation in memory (or registers, etc) within a binary digital computer. XML is character-based and would implement the maximum 32-bit signed value as "2147483647" (my quotes, of course), which is a lot more than 32 bits! What IS true is that xs:int is (indirectly) a restriction of xs:integer which sets the maximum and minimum allowed values to be the same as the corresponding implementation-imposed limits of a 32-bit integer with a sign bit.

Swastika

There is no guarantee that the source infoset validated with XSD comes in the form of a sequence of characters; if the schema is used to validate a document instance constructed by means of XSLT or XQuery, there is every possibility that an xs:int value could be represented in memory using the conventional representation for 32-bit integers. – Minuteman

@C.M.Sperberg-McQueen, I'm not sure I understand your point. xs:int is a type with a range, how it's stored is irrelevant to the XSD and anything that hard codes "int" as a 32 bit signed integer in memory is asking for problems if, for example, a different XSD is chosen that says an int has a range different to the range as defined in the w3c XSD. – Harlanharland

@PaulHargreaves it's a slightly pedantic point (in the spirit of the answer). The answer is right that it's not correct to say flatly that xs:int is a signed 32-bit twos-complement integer. But the answer also says that since XML is character-based, the maximum value of xs:int is the character string "2147483647"; that last bit ain't necessarily so. XSD types are used by plenty of systems, e.g. XQuery databases, where an xs:int value is more likely to be represented in a 32-bit twos-complement field than as a string of Unicode characters. – Minuteman

use "represents" in place of "is" – Ramification