[6 December 2012]

I recently had occasion to write an XSD 1.1 schema for a client whose data includes ISBN and ISSN values.

In a DTD, all one can plausibly say about an element which is supposed to contain an ISBN is that it contains character data, something like this:

<!ELEMENT isbn (#PCDATA) >

That accepts legal ISBN values, like “0 13 651431 6” and “978-1-4419-1901-4”, but it also accepts strings with invalid check-digits, like “0 13 561431 6” (inversion of digits is said to be the most common single error in typing ISBNs), and strings with the wrong number of digits, like “978-1-4419-19014-4”. For that matter, it also accepts strings like “@@@ call Sally and ask what the ISBN is going to be @@@”. (There may be stages in a document’s life when you want to accept that last value. But there may also be stages when you don’t want to allow anything but a legal ISBN. This post is about what to do when writing a schema for that latter set of stages in a document’s life.)

In XSD 1.0, regular-expression patterns can be used to say, more specifically, that the value of a ten-digit ISBN should be of a specific length (thirteen, actually, not ten, because we want to require hyphens or blanks as separators) and should contain only decimal digits, separators, and X (because X is a legal check-digit).

<xsd:simpleType name="ISBN-10">
  <xsd:restriction base="xsd:string">
    <xsd:length value="13"/>
    <xsd:pattern value="[0-9X \-]*"/>
  </xsd:restriction>
</xsd:simpleType>

Actually, we can do better than that. In a ten-digit ISBN, there should be ten digits: one to five digits in the so-called group identifier (which divides the world in language / country areas), one to seven digits in the publisher code (in the US, all publisher codes use at least two digits, but I have not been able to find anything that plausibly asserts this is necessarily true for all publisher codes world-wide), one to seven in the item number, and a final digit (or X) as a check digit.

<xsd:simpleType name="ISBN-10">
  <xsd:restriction base="xsd:string">
    <xsd:length value="13"/>
    <xsd:pattern 
      value="[0-9]{1,5}-[0-9]{1,7}-[0-9]{1,7}-[0-9X]"/>
    <xsd:pattern 
      value="[0-9]{1,5} [0-9]{1,7} [0-9]{1,7} [0-9X]"/>
  </xsd:restriction>
</xsd:simpleType>

Since the number of separators is fixed, and the total length of the string is fixed, the type definition above will only accept literals with exactly ten non-separator digits. The patterns above assume that either hyphens or blanks will be used as separators, not a mix of hyphens and blanks; they also want any X appearing as a check-digit to be uppercase.

A similar type can be defined for thirteen-digit ISBNs, which add a three-digit industry-code prefix and another separator at the beginning:

<xsd:simpleType name="ISBN-13">
  <xsd:restriction base="xsd:string">
    <xsd:length value="17"/>
    <xsd:pattern 
      value="(978|979)-[0-9]{1,5}-[0-9]{1,7}-[0-9]{1,7}-[0-9]"/>
    <xsd:pattern 
      value="(978|979) [0-9]{1,5} [0-9]{1,7} [0-9]{1,7} [0-9]"/>
  </xsd:restriction>
</xsd:simpleType>

In XSD 1.0, that’s as much as we can conveniently do. (Well, almost. If we are willing to endure the associated tedium, we can check for the correct positioning of hyphens in at least the ISBNs of some areas which assign publisher codes in such a way as to ensure that ISBNs remain unique even if the separators are dropped. See the ISBN datatype defined by Roger Costello and Roger Sperberg for an illustration of the principle.)

In theory, we ought to be able to do better: the check-digit algorithm can be checked by a finite-state automaton, and the languages of ten-digit and thirteen-digit ISBNs are thus demonstrably regular languages. So in principle, there are regular expressions that can perform the check-digit calculation. When I have tried to translate from the FSA to a regular expression, however, the result has been uncomfortably long.

But in XSD 1.1, the addition of assertions makes it possible to replicate the check-digit algorithm. We can write a type definition similar to the ones given above, with an additional xsd:assertion element whose test attribute has as its value an XPath expression which will validate the check-digit.

The ISBN-10 check-digit is constructed in such a way that the sum of digit 1 × 10 + digit 2 × 9 + … + digit 8 × 3 + digit 9 × 2 + digit 10 (if digit 10 is a digit, or 10 if digit 10 is an X), modulo 11, is equal to 0. The ISBN-13 check-digit uses a similar but simpler calculation: the numeric values of digits in even-numbered positions are multiplied by three, those of the digits in odd-numbered positions by one, and the sum of these weighted values must be a multiple of ten. This calculation is well within the range of XPath 2.0; let us build up the expression in stages.

Given a candidate ISBN in variable $value, we can obtain a string of digits (or X) without the separators by deleting all hyphens and blanks, which we can do in XPath by writing:

translate($value,' -','')

We can turn that, in turn, into a sequence of numbers (the UCS code-point numbers for the characters) using the XPath 2.0 function string-to-codepoints:

string-to-codepoints(translate($value,' -',''))

For example, given the ISBN “0 13 651431 6”, as the value of $value, the expression just given evaluates to the sequence of integers (48 49 51 54 53 49 52 51 49 54). For purposes of the checksum calculation, however, we’d rather have a 0 in the ISBN appear as a 0, not a 48, in our sequence of numbers. And we need to turn X (which maps to 88) into 10. So we write the following XPath 2.0 expression:

for $d in string-to-codepoints(translate($value,' -',''))
return if ($d = 88) then 10 else ($d - 48)

Now the ten-digit ISBN “0 13 651431 6” and the thirteen-digit ISBN “978-1-4419-1901-4” map, respectively, to the sequences (0 1 3 6 5 1 4 3 1 6) and (9 7 8 1 4 4 1 9 1 9 0 1 4). This gives us precisely what we need for doing the arithmetic.

From the integer sequences thus created, we can extract the first digit by writing the filter expression [1], the second digit with [2], etc. It would be convenient to be able to assign the integer sequence to a variable, but that’s not possible in XPath 2.0 (at least, not using normal means). In writing the schema document, however, we can put the expression that generates the sequence into a named entity, thus:

<!ENTITY digit-sequence 
"(for $d in string-to-codepoints(translate($value,' -',''))
  return if ($d = 88) then 10 else ($d - 48))">

Now we can write the assertion for ISBN-10 thus:

<xsd:assertion test="
        ((&digit-sequence;[1] * 8
        + &digit-sequence;[2] * 7
        + &digit-sequence;[3] * 6
        + &digit-sequence;[4] * 5
        + &digit-sequence;[5] * 4
        + &digit-sequence;[6] * 3
        + &digit-sequence;[7] * 2
        + &digit-sequence;[8] * 1) mod 11) eq 0
        "/>

We could write a similar expression for ISBN-13, but in fact we can use simple arithmetic to simplify the expression to:

<xsd:assertion test="
        ((sum(&digit-sequence;
             [position() mod 2 = 1]) 
        + sum(for $d in (&digit-sequence;
                         [position() mod 2 = 0]) 
              return 3 * $d)
        ) mod 10) eq 0
        "/>

(Digression on entities …)

Some people, of course, frown on the use of entities in XML and claim that they are not helpful. I think examples like this one clearly show that entities can be very useful when used intelligently; it is much easier to see that the assertions given above are correct than it is in the equivalent assertions after entity expansion (post-edited to provide better legibility):

<xsd:assertion test="
  (((for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [1] * 10         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [2] * 9         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [3] * 8         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [4] * 7         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [5] * 6         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [6] * 5         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [7] * 4         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [8] * 3         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [9] * 2         
  + (for $d in string-to-codepoints(translate($value,' -','')) 
     return if ($d = 88) then 10 else ($d - 48)) [10] * 1) 
  mod 11) 
  eq 0
  "/>      

<xsd:assertion test="
   ((sum(
      (for $d in string-to-codepoints(translate($value,' -','')) 
       return if ($d = 88) then 10 else ($d - 48)
      )[position() mod 2 = 1]
     )          
   + sum(for $d in 
          ((for $d in 
              string-to-codepoints(translate($value,' -','')) 
            return if ($d = 88) then 10 else ($d - 48)
           ) [position() mod 2 = 0]) 
         return 3 * $d)) 
   mod 10) 
   eq 0
   "/>

The use of entity references makes it far easier to be confident that the two, or ten, for-expressions all really do the same thing, and they provide a level of abstraction which, in a simple way, encapsulates the book-keeping details and allows the overall structure of the two test expressions to be more clearly exhibited.

(End of digression.)

The end result is an XSD 1.1 datatype that detects most typos in the recording of ISBNs. It does not, alas, ensure that the legal ISBN one types in is actually the correct ISBN, only that it is a correct ISBN. But using machines to check what machines can check will leave more time for humans to check those things that only humans can check.