It is important to validate each field until it is either valid or an error has been detected. The order of testing data is to first check for missing data. Then a syntax test can check the length of the data entered and check for proper class and composition. Only after the syntax is correct are the semantics, or meaning, of the data validated. This includes a range, reasonable, or value test, followed by a check digit test.
GUI screens help to reduce the number of human input errors when they incorporate radio buttons, check boxes, and drop-down lists. When radio buttons are used, one should be set as the default, and the only way it would be unchecked is if the user clicks a different radio button. In the case of drop-down lists, the first choice should contain a message informing the user to change the list. If the first choice is still selected when the form is submitted, a message should inform the user to select a different option.
Usually validating a single field is done with a series of IF . . . ELSE statements, but there are also pattern validation methods. Usually these patterns are found in the database design (as in Microsoft Access) but may be included in programming languages, such as Perl, JavaScript, and XMLschemas. The patterns are called regular expressions and contain symbols that represent the type of data that must be present in a field. Table shown below illustrates characters used in JavaScript regular expressions.
| Character Code | Meaning Used in Regular Expression Validation |
|---|---|
| \d | Any digit 0–9 |
| \D | Any nondigit character |
| \w | Any letter, number, or underscore |
| \W | Any character other than a letter, number, or underscore |
| . | Matches any character |
| [characters] | Matches the characters in the brackets |
| [char-char] | Matches the range of characters |
| [a–z][A–Z][0–9] | Will accept any letter or digit |
| [^characters] | Match anything other than the characters |
| [^char-char] | Match anything outside the range of characters |
| [^a–z] | Will accept anything except lowercase letters |
| {n} | Match exactly n occurrences of the preceding character |
| {n,} | Match at least n occurrences of the character |
| \s | Any white space formatting character (tab, new line, return, etc.) |
| \S | Any nonwhite space character |
An example of pattern validation used to test an email address is
[A-Za-z0-9]\w{2,}@[A-Za-z0-9]{3,}\.[A-Za-z]{3}/
The meaning of this pattern is as follows: The first letter must be any uppercase letter, lowercase letter, or number ([A-Za-z0-9]). This is followed by two or more characters that are any letter, number, or an underscore (\w{2,}). There must then be an @ symbol, followed by at least three letters or numbers, a period, and exactly three characters after the period.
A cross-reference check assumes that the validity of one field may depend on the value of another field. An example of a cross-reference check is checking for a valid date. In one very special case, the validity of the day of the month depends on the year. That is, February 29 is only valid during leap years. Once single fields have been checked, you can perform cross-reference checks. Obviously, if one of the fields is incorrect, the cross-reference check is meaningless and should not be performed.
XML documents may be validated by comparing them to a document type definition (DTD) or a schema (refer to Chapter 8). The DTD will check to see whether the format of the document is valid, but a schema is much more powerful and will check the type of data, such as a short or long integer, a decimal number, or date. A schema will also check a range of values, the number of digits to the left and right of a decimal point, and the values of codes. There are free tools to validate a DTD or schema. IEXMLTLS is a Microsoft extension to Internet Explorer that adds new menu options when the user right-clicks in an XML document.
