The definition of card-number datatype

I was doing a pubrules and link check on the XForms 1.1 spec and noticed 
that we inadvertently failed to remove the bibliography citation of ISO 
7812 in the section 5 description of the card-number datatype, despite 
having deleted the normative bibliography reference to ISO 7812.

By way of reminder, the working group agreed to restate the definition of 
the card-number datatype and is-card-number() function without referencing 
ISO 7812 because you have to pay for that spec.

So I had to remove the citation in section 5 and simply state the 
limitation of 12 to 19 digits that is specified by the schema definition. 
No problem so far.

However, while looking into the issue, I noticed that the only normative 
reference we now make regarding the definitions of card-number and 
is-card-number() is the "Luhn Patent", which is now in the public domain.

If you search for "Luhn Patent" with Google, you are immediately provided 
with a wikipedia entry describing the algorithm.

However, the example used illustrates the Luhn calculation for a nine 
digit number.  It turns out that Canadian social insurance number are 9 
digits and are validated by the Luhn algorithm.

It was OK to restrict ourselves to 12 to 19 digits when the definition was 
based on ISO 7812, but now that it is not and given that the Canadian SIN 
card number is a legitimate "card number" of length 9, it seems clear that 
the min length restriction should be relaxed. 

Of interest, the Luhn patent describes and illustrates a non-digital 
(mechanical) embodiment of the invention based on 7 digits, excluding the 
check digit.  Moreover, I saw no explicit mention of a minimum number of 
digits, only an implicit statement of minimum length based on the claimed 
intent to detect digit transpositions that would otherwise go undetected 
in numbers consisting of a "plurality of digits".   Hence a minimum length 
restriction of 3 seems reasonable, and any larger minimum seems 
unnecessarily restrictive.

One might think at first that this change might be detrimental to the 
desire to use the card-number datatype for validation of credit card 
number entries.  However, the restriction to 12 to 19 digits is already 
too loose.  If one has a 16 digit card number but enters only 15 or 
perhaps 17 digits, then card-number reports validity, and the error must 
be trapped with is-card-number() anyway.  The only valuable service 
provided by the card-number datatype is the restriction to digits.  Any 
length restriction, min or max, is not very useful, and as we are seeing 
now, the restrictions are in fact detrimental.

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer