query on element with pattern gives Runtime type exception

A query (generated by XApplication) on an element with a pattern:
for $x in input()/abc[/abc/IDNumber=‘0012310000000’] return $x
gives the following error:
<ino:message ino:returnvalue=“6301”>
<ino:messagetext ino:code=“INOXQE6301”>Runtime type exception</ino:messagetext>
</ino:message>

Can somebody please tell me what is wrong with the type?

Sample tsd attached
sample.tsd (9.74 KB)

Hello,

you are using ‘integer’ for the attribute defintion. The value ‘0012310000000’ you entered is not a legal integer according to the schema defintion. Please have a look into the schema primer

http://www.w3.org/TR/xmlschema-0/

Basic types as ‘integer’ are described here as well as ‘pattern’. If you want leading Zeros for your values, I woud propose the basic type ‘string’ and adapt the pattern.

Bye,
Christian.

I blush with embarrassment - I assumed that XApplication would generate a valid query and never looked any further! I will change the definition to a string. Thanks for the help.

IDNumberType is defined by restriction from integer, so it can’t be compared with a string.

Deriving IDNumberType from integer is probably not a good idea, since leading zeros appear to be significant. In fact, using a pattern facet in the type definition of an integer is not going to work well. If you try to output an IDNumberType, this will involve a string to integer conversion, and the conversion will always produce an integer with no leading zeros, which then fails validation against the pattern. If the leading zeros really are significant, then I think you should derive IDNumberType from string, not from integer.

What it comes down to is that 001 and 1 are two different representations of the same integer. If you want to treat these two values differently, for validation or comparison or anything else, then they are not really integers, and shouldn’t be described as such.

Michael Kay

Thanks, Michael, for the explanation. I have changed IDNumberType to a string and it works like a charm. I see now that it shouldn’t have been described as an integer at all. By the way the first 6 digits are YYMMDD so the leading zeroes ARE significant. XApplication doen’t seem to generate the correct query for any integer so the fact there was a pattern was a red herring.