RE: The definition of card-number datatype

John,
Your observation that the luhn function cannot check length and the
Schema validity length limits are also under-constrained further
supports my position that the primary value of the card type is not the
machine-readable constraints, but that as a well-known type user agents
are encouraged to provide custom UI (much as they do for boolean), and
allow the user to enter hyphens or spaces as desired, but still fashion
the resulting lexical space value properly.
Leigh.

________________________________

From: public-forms-request@w3.org [mailto:public-forms-request@w3.org]
On Behalf Of John Boyer
Sent: Thursday, November 22, 2007 5:54 PM
To: Forms WG (new)
Subject: 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
<http://www.ibm.com/developerworks/blogs/page/JohnBoyer>