Method of Facilitating Computer Sorting

This invention relates generally to alphabetical sorting by computer, and more particularly to the alphabetical sorting, by computer, of words based upon a multilingual alphabet.

To date, the most widely used code standard for alphanumeric characters has been ASCII (American Standard Code for Information Interchange) which is a 7-bit binary code standardized by ANSI (American National Standards Institute). As the only letters that ASCII supports are the English letters, its implementation in information processing and interchange environments has been limited to English. As a result, a large number of computer systems today communicate in the English language only.

In recent years, the computer industry has recognized the need to support the non-English Latin-based languages in order to facilitate communication with a non-technical user who often is familiar with only his native language. Hence, a new 8-bit multilingual character set was defined by ISO (International Standards Organization) in 1986. That set has already gained a broad support from the industry and various national standard organizations. The name of the character set is Latin Alphabet #1 and it has been documented in the ISO Standard as ISO 8859/1. It supports 14 Western European and Western Hemisphere languages that are used in 45 countries around the world.

The set of languages and characters supported by the ISO standard ISO 8859/1--"Information Processing--8 bit single byte coded graphic character sets Part Latin Alphabet #1" is believed to include most of those that are used in North America, Western Europe and Western Hemisphere. They are listed below:

Danish, Dutch, English, Faeroese, Finnish, French, German, Icelandic, Irish, Italian, Norwegian, Portuguese, Spanish and Swedish. These languages are believed used in at least the following countries:

Returning now to the ASCII Character set, the main advantage embodied by the English language with regard to sorting is that the alphabetical order of the letters in the English alphabet corresponds to the internal numerical collating sequence in the ASCII set. This special feature makes the sorting of English language strings relatively simple and in most cases efficient.

For example, to sort two characters, the following operations are performed:

(1) Convert the cases of both characters into the same one (i.e. the characters become caseless).

(2) Use straight comparison of codes (ordinal values) of both characters to determine the relative sort orders. The character whose ordinal value is smaller is collated first (in ascending order sorting).

Some limitations of this method of sorting, based upon the ASCII character set, include the following:

(1) Most, if not all sorting algorithms published so far assume that the underlying character set is the 7-bit ASCII set (or in some rare cases the EBCDIC set) which does not support foreign letters. As a result, these algorithms are not capable of sorting properly most non-English Latin-based languages.

(2) The existing sorting methods for English and other languages cannot handle sorting properly when foreign letters are included. This should never happen if the computer system uses the national character sets which contain only letters in their languages. However, the problem of dealing with foreign letters in sorting does come up when 8-bit character sets are supported since those sets contain more letters than those that are used domestically.

(3) The existing algorithms cannot properly handle sorting in a multilingual environment in which information from the same database can be accessed by users using different languages.

To handle multilingual sorting properly, the following issues should be addressed.

(1) The collating sequence of letters in the Latin Alphabet #1 (or any other multilingual set) does not correspond to the alphabetical order of the letters in all the supported languages. This means sorting can no longer rely on the collating sequence imposed by the character set.

(2) The main idea of sorting in a multilingual environment is to have data sorted in the user's own language. The data stored does not have to be necessarily in the user's language and, in fact, it can be made up of several different languages. Hence, a sorting operation is needed that is capable of supporting different sorting orders dependent on the users' languages. For example, the letter "A" is sorted after "Z" in Swedish whereas it is sorted the same as an "A / " in German.

(3) In some languages, there are cases where letters with different internal representation are sorted as if they had the same representation (e.g. "V" and "W" in Swedish are collated the same). This undoubtedly creates a difficulty if one is thinking about using internal representation as a means to tackle the sorting problem.

(4) The sorting software should be able to collate foreign letters correctly among the domestic letters. This kind of transliteration is definitely language dependent.

To give a better picture of the problems when multilingual character sets are supported, the sort orders of four illustrative languages are outlined below. Language 1 might be English, language 2 might be Swedish, language 3 might be German and language 4 might be French. Letters which have the same alphabetical order are enclosed in braces. Note that priority rules apply to those letters which are enclosed in braces and differ only by accent.

(1) Language 1:

Lower case: a b c d e f g h i j k l m n o p q r s t u v w x y z

Upper Case: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

(2) Language 2:

Lower Case: a b c d {e e} f g h i j k l m n o p q r s t u {v w} x {y U} z .ang. a o

Upper Case: A B C D {E E} F G H I J K L M N O P Q R S T U {V W} X {Y U} Z .ANG. A o

(3) Language 3:

Lower Case: {a a} b c d e f g h i j k l m n {o o} p q r s .beta. t {u u} v w x y z

Upper Case: {A A} B C D E F G H I J K L M N {O o} P Q R S .beta. T {U U} V W X Y Z

(4) Language 4:

Lower Case: {a a a} b {cc} d {e e e,gra/e/ e e} f g h {i i i} j k l m n {o o} p q r s t {u u u u} v w x y z

Upper Case: {A A A} B { C c}D {E E E E E} F G H {I I I} J K L M N {O O} P Q R S T {U U U U} V W X Y Z

The character set defined in ISO 8859/1 has received wide support from the computer industry in both North America and Western Europe. The new sorting methods of the present invention can be incorporated into computer systems that are based on the above character set standard. Also, the methods can be applied to systems that use other 8-bit one-byte encoded character set standards with only minor modifications.

The sorting methods of the present invention allow the same algorithm (software) to support any of the 14 languages listed earlier. The main reason is that the present invention uses a standard encoding scheme to encode sort orders for all the letters defined in ISO 8859/1. This encoding scheme removes the dependency of sorting on the character set's internal collating representation.

By storing the language dependent sort orders as data files, the sorting software is immune to the users' languages and hence is highly portable and cost effective since only one set of software has to be maintained. The number of languages supported is directly proportional to the number of data files available. This implies no software changes are needed when a new language is supported. Instead, a new data file has to be defined and installed.

To support the sorting of foreign letters, "transliteration" is used to ensure foreign letters are sorted where users are most likely expected to look for them. This includes both geometrical similarity and phonetic rules.

The sorting methods of the present invention support the following features:

(1) Characters that do not appear in a language should be sorted where users of that language might be expected to look for them.

(2) In all cases, all punctuations and non-alphanumerical characters except blank are to be ignored if they appear among numerics and alphabetics (e.g. Ada/Bobby Co. is sorted as AdaBobby Co). If the name contains just punctuations and/or non-alphanumerical characters, then those characters should be preserved (e.g. ***, [*], /*/, etc.). In this case, these non-alphanumerical characters would be ordered before the digits and letters.

(3) Sorting operations must support one-to-two substitutions for some characters. For example, the `.beta.` from language 3 is sorted as though it were "ss" in language 1.

(4) Sorting operations must support two-to-one substitutions for some characters. For example, in Spanish the letter pairs `ch` and `ll` are sorted as if they were single letters and they are sorted between `cz` and `d` and between `lz` and `m` respectively.

(5) Sorting operations must support accent priority. This means accented/non-accented letters are given different ordering when all the letters in the strings being compared are equal except for the accents (e.g. "Ellen" is collated before "Ellen"). For example, in English the `a` vowels (with or without accent) are treated as equal except for priority. Their priority order is: A A A A A A .ANG.. Note that priority among accents might vary between different languages.

(6) The sort orders among non-alphanumerical characters (punctuations and symbols) are not expected to be language dependent. Hence, the language dependency of sorting would be determined by letters and accents.

The present invention is directed to a method of tokenizing sorting orders apart from using internal collating sequences imposed by the character set employed, including the step of transliterating "foreign" letters according to geometrical or phonetic similarity for the purpose of defining the sorting order.

Stated in other terms, the present invention is a method of facilitating the alphabetical sorting, by computer, of words based upon characters from a multilingual alphabet, the method characterized by the steps of maintaining a master file of the words to be sorted and providing a data file for each language to be supported, the data file provided to facilitate modification of the master file in a predetermined fashion prior to performing the alphabetical sorting whereby the words are put into a form independent of a specific language character set's internal representation for the subsequent act of alphabetization.

The invention will now be described in more detail with reference to the accompanying drawings wherein like parts in each of the several figures are identified by the same reference character, and wherein:

FIG. 1A is a simplified block diagram depicting the record structure of the present invention for handling the alphanumerical characters supported by ISO 8859/1;

FIG. 1B is a simplified block diagram depicting an alphanumerical character encoding table for the present invention;

FIG. 2A is a simplified block diagram depicting the record structure of the present invention for handling the priorities of accents supported by ISO 8859/1;

FIG. 2B is a simplified block diagram depicting an accent encoding table for the present invention;

FIG. 3A is a simplified block diagram depicting the record structure of the present invention for handling the non-alphanumerical characters supported by ISO 8859/1;

FIG. 3B is a simplified block diagram depicting a non-alphanumerical character encoding table for the present invention;

FIG. 4 is a simplified block diagram depicting the overall sortkey encoding process of the present invention;

FIG. 5 is a simplified block diagram depicting the composition of a sortkey entry, encoded according to the present invention;

FIG. 6 is a simplified block diagram depicting how language dependent data files are created with an off-line utility which is used to translate sort orders into data files needed by the encoding software;

FIG. 7 is a simplified pictorial representation of the actual encoding step performed by the present invention on an illustrative alphabetical example;

FIG. 8 is a simplified pictorial representation of the actual accent priority encoding step performed by the present invention on an illustrative example;

FIG. 9 is a simplified pictorial illustration of a complete data sortkey;

FIG. 10 is a simplified pictorial representation of the actual encoding steps performed by the present invention on an illustrative non-alphanumerical example;

FIG. 11 is a chart depicting Latin alphabet #1 of ISO 8859/1;

FIGS. 12, 13, 14A and 14B are simplified flow charts useful for understanding the present invention;

Appendix A is a simplified pseudocode listing useful for understanding the present invention;

Appendix B is a glossary of certain terms used in the description of the present invention;

Appendix C is a table showing the correspondence between the characters of some different languages;

Appendix D is an alphanumerical character encoding table for language 1;

Appendix E is an alphanumerical character encoding table for language 5;

Appendix F is an accent priority encoding table for languages 1 and 5; and

Appendix G is a non-alphanumerical character encoding table for languages 1 and 5.

Unlike the sorting sequence of ASCII, the sorting sequences of the ISO 8859/1 characters do not correspond to any of the sort orders of the fourteen languages supported by the present invention. According to the present invention, language dependent sortkeys which are based on users' languages are formed before normal sorting packages can be used.

The present invention permits language dependent sorting to be handled by language independent software. This means that the same set of software is portable to support sorting when different languages have to be supported. The language dependent sort orders are loaded from data files at run time. The sort orders are created by a utility program which creates the data for the three encoding tables (tables 120, 126, and 131 of FIGS. 1B, 2B, and 3B respectively) used by the encoding software (Appendix A).

There are two encoding tables (an alphanumerical character encoding table 120, FIG. 1B, and an accent priority encoding table 126, FIG. 2B) associated with each language supported, whereas the third table (non-alphanumerical character encoding table 131, FIG. 3B) is common for all the languages supported (as listed under the section "Background of the Invention"). Each table has 256 entries so that all characters supported by the ISO 8859/1 character set can be represented.

The alphanumerical character encoding records 20 (FIG. 1) are used to encode digits (numerical characters) and letters (alphabetical characters). Each character requires four bytes of information. Byte 21 is used to indicate whether the encoding is 1-to-1, 1-to-2, 2-to-2, or ignore. Note that "0" indicates 1-to-1, "1" indicates 1-to-2, "2" indicates 2-to-2, and "255" indicates ignore.

If encoding indicator 21 is "0" (i.e. 1-to-1), then only the first encoded sort order byte 22 is used to store the encoded sort order of the character entry whereas the second encoded sort order byte 23 and the next largest sort order byte 24 are unused.

If encoding indicator 21 is "1" (i.e. 1-to-2), then the first encoded sort order byte 22 and the second encoded sort order byte 23 are both used to store the two corresponding encoded sort orders of the character entry and the next largest sort order byte 24 is unused.

If encoding indicator 21 is "2" (i.e. 2-to-2), then all the other three bytes (first encoded sort order 22, second encoded sort order 23, and next largest sort order 24) will be used to store encoding information. The first encoded sort order 22 is used to store the encoded sort order of the character entry (e.g. the value 78 for the character "C", FIG. 7). The second encoded sort order 23 is used to store the encoded sort order of the second character of the pair (e.g. the value 83 for the letter "H" in the two character pair "CH"). The next largest sort order 24 is used to store the encoded sort order of the largest sort order defined in that language (e.g. 102 in the FIG. 7 example).

Encoding indicator byte 21 provides the correct response for both the cases of 1-to-1 and 1-to-2, but it could provide an incorrect response in the case of 2-to-2. This occurs because extra checking is required to determine whether or not the encoded sort order of the next input character matches that of the second character in the two-character pair which is stored in byte 23. As a result, encoding indicator 21 is enabled for the 2-to-2 situation (i.e. is "2") for characters which can potentially be the prefixes of the two-character pairs (e.g. "C" and "L" for Spanish). The actual encoded sort order for the second character of the two-character pair is stored in byte 24 which represents the highest encoded sort order value for that language (e.g. for the Spanish language it means the encoded value after the value for the letter "Z"). As usual, the encoded sort order for the character entry is still stored in byte 22. The actual values for the encoded sort orders for numerals and letters must be greater than those defined for the non-alphanumerical characters. If encoding indicator byte 21 is ignore (i.e. 255), then the character's encoding value can be ignored. This applies to control characters defined with code values Hex 00 to Hex 1F and Hex 80 to Hex 9F and non-alphanumerical characters Hex 21 to Hex 2F, Hex 3A to Hex 3F, Hex 40, Hex 5B to Hex 5F, Hex 60, Hex 7B to Hex 7F, and Hex A1 to Hex BF.

The accent priority encoding records 26 (FIG. 2A) are used to encode accents which are needed to support character priority. For those characters that can be accented (e.g. "A" and "E"), the first encoded accent value 27 is zero and the second encoded accent value 28 is unused since these characters require only 1-to-1 character encoding and this applies to accent encoding as well. The accent encoding values (27 and 28) start at 0 and go up based on the number of accents available. Note that the encoded accent values 27 and 28 are only significant in terms of sorting when the data is identical except for the accents.

For those characters that require 1-to-2 encoding, values 27 and 28 are used to store the encoded accent values of the two characters that are transliterated. The prefixes of the two-character pair (e.g. "C" and "L" for Spanish) are encoded the same way as other characters and no special accent encoding values are needed (i.e. they are encoded the same way as other 1-to-1 encoding characters). The accent values of those character-pairs that require 2-to-2 encoding depend on the transliterated characters (i.e. the largest sort order) which, however, do not embody accents and hence their encoded accent values are undefined.

The non-alphanumerical character encoding records 31 (FIG. 3A) are used to encode all other printable characters except numerals and letters. Those characters are assigned encoding values from 1 upward and are stored in encoded sort order 32. The last encoding value plus one in this category will be the starting value for the encoded sort orders used for the alphanumerical characters.

The overall sortkey encoding process 33 is depicted in FIG. 4. Data 34 (i.e. words) after being encoded by software 35, which uses language dependent data files 36 as encoding table, transforms data 34 into language dependent sortkeys 37. The sortkeys 37 can then be used for comparison during the actual sorting operation.

FIG. 5 depicts, in more detail, the structure of an encoded sortkey 37. The encoded sortkey 37 is longer than the original data due to the presence of the encoded accent priority values 40. Encoded sortkey 37 is comprised of encoded sort orders 39 and encoded accent values 40. The increase in the length of encoded sortkey 37 (over the length of the original data) can at most be one-half the size of the original data if all characters in the data have accent priority values This occurs because encoded accent priority values 40 are packed two values into one byte since the values range from 0 to 10; hence each value fits into 4 bits. Note that encoded accent priority values 40 are stored in the encoded sortkey 37 only for letters that can be accented (e.g. "A" and "E") or for actually accented letters (e.g. "A" and "E"). This means that for data that contains only numerals, letters that cannot be accented (e.g. "X" and "Z") and non-alphanumerical characters, there will be no increment in the size of encoded sortkey 37 over that of the raw data.

FIG. 6 is a simplified block diagram depicting the sort orders definition utility 41. The language dependent data files 36 needed by the overall sortkey encoding process 33 (FIG. 4) are created by an off-line data file construction process 41 (FIG. 6) which takes the sort order information 42 of each particular language and uses the sort orders definition utility 43 to build up the three encoding tables referred to as language dependent data files 36 (i.e. alphanumerical encoding table 120, FIG. 1B, accent priority encoding table 126, FIG. 2B, and non-alphanumerical character encoding table 131, FIG. 3B). The use of data files 36 separates the sorting software from the language dependency of the sort orders and allows the use of one set of sorting software

FIGS. 7 and 8 are pictorial representations of the actual encoding of an arbitrary sample word or data "BCH ." shown at 46. The encoded version of the alphanumerical portion of this word is shown in encoded form in FIG. 7 as alphanumeric sortkey 47. The encoded version of the accent attribute portion of word 46 is shown in encoded form in FIG. 8 as accent sortkey 48. The complete encoded version of word 46, referred to as data sortkey 49, is shown in FIG. 9 and consists of alphanumeric sort key 47 followed by accent sortkey 48.

FIG. 7 illustrates the four possible actions that can occur in the alphanumerical encoding process: i.e. 1-to-1, 2-to-2, 1-to-2, and ignore. The example given is based on a language 5 (which might be Spanish) alphanumerical character encoding table and is given for illustrative purposes only.

The first step in the encoding process is to check the first character in word 46, i.e. the character "B" against its corresponding encoding indicator 51. This is indicated in FIG. 7 by line 61 extending from the character "B" in the word 46 to the B entry in character column 50 of Alphanumerical Character Encoding table 56 which has as a corresponding entry in encoding indicator column 51 the value "0" indicating that the encoding is 1-to-1. Hence, the corresponding encoded sort order (i.e. "77") is fetched from first encoded sort order column 52 and put into the first position of Alphanumeric sortkey 47 as indicated by the line 62.

The character "B" is checked again to see if any accent priority has to be stored (see FIG. 8). As indicated by line 63, in FIG. 8, extending from the character "B" in word 46 to the B entry in character column 57 of Accent Priority Encoding table 60 which has as a corresponding entry in first encoded accent value column 58 the value "255". The value "255" in column 58 indicates that this character cannot contain an accent and hence no value is needed to be stored in accent sortkey 48.

The same checking step against character column 50 of Alphanumerical Character Encoding table 56 (FIG. 7) is repeated for the next character in word 46, i.e. the letter "C", as indicated by line 64. The corresponding entry in encoding indicator column 51 is the value "2" which indicates that 2-to-2 encoding might be required. To determine whether or not this is indeed the case, the next letter in word 46, i.e. the letter "H" is encoded, as indicated by line 66 extending from the character "H" in word 46 to the H entry in character column 50 which has as a corresponding entry in first encoded sort order column 52 the value "83". This value is then compared against the one stored in second encoded sort order column 53, corresponding to the character "C" (which has the value "83"). Since the values are identical (both have the value "83"), this indicates that a character-pair is present (i.e. the characters "CH" must be treated as one unit and not as two separate characters: i.e. 2-to-2 encoding is required). The value "78" from first encoded sort order column 52, corresponding to the letter "C", is put into the second position of alphanumeric sortkey 47 as indicated by line 67. The next largest sort order column 54, corresponding to the character "C" (i.e. value "102") is put into the third position of sortkey 47 as indicated by line 68. No checking is needed for accent priorities as no accent is defined for the next largest sort order column 54 and the accent priority for the first character of the character-pair (i.e. C) can be ignored since it will never be used (note that this information can be extracted from encoding indicator 51 which has the value 2 in this instance).

If the encoded sort order of the character after "C" in the input data were not "83" as indicated by the entry in the second encoded sort order column 53 against the character "C" entry, then only the first encoded sort order of the character "C" (i.e. "78" as found in column 52) would be put into the second position of sortkey 47.

Next, the character " " is encoded, as indicated by line 69 between the character " " in word 46 and the entry " " in column 50 of encoding table 56. The entry in encoding indicator column 51 corresponding to the character " " has the value "1". This indicates that the character requires 1-to-2 encoding. As a result, the values (encoded sort orders) from columns 52 and 53 (i.e. values "76" and "80" respectively) are placed into the next two positions of alphanumeric sortkey 47 as indicated by the lines 71 and 72.

As shown in FIG. 8, the character " " is checked against Accent Priority Encoding Table 60 as indicated by line 73. This action reveals that the character " " has two accent attributes and hence the two encoded accent values, each of which is "0", are fetched and put into accent sortkey 48 as indicated by lines 74 and 76.

The final character in word 46 is a period(.). It is checked against encoding table 56 (FIG. 7) as indicated by line 77. The entry in column 51 against the character "." is the value "255" which indicates that no encoding value is needed and that therefore this is an ignore situation. This value is therefore not added to alphanumeric sortkey 47. The same thing occurs in FIG. 8 when the accent priority is checked, as indicated by line 78.

FIG. 9 depicts the complete data sortkey 49 for the original word 46. Data sortkey 49 comprises alphanumeric sortkey 47 followed by accent sortkey 48 (depicted before packing two bytes into one) as shown in the Figure.

FIG. 10 illustrates the invention for the situation when data 81 contains only non-alphanumerical characters. Each character is encoded using the Non-alphanumerical Character Encoding table 84. The first symbol in data 81, i.e. asterisk * is checked against the asterisk * in symbol column 85 of Non-Alphanumerical Character Encoding table 84. This is indicated by line 86; the corresponding entry in encoded sort order column 83 of table 84 is the number "11". This number is then placed in the first position of sortkey 82 as indicated by line 87. The same steps apply for the second asterisk in data 81.

Similar steps apply for the symbol @; the symbol @ in data 81 is checked against the symbol @ in symbol column 85 of table 84 as indicated by line 88. The corresponding entry in encoded sort order column 83 of table 84 is the number "23". This number is then placed in the third position of sortkey 82 as indicated by line 89.

Finally, the same steps are applied to the final symbol of data 81, namely the symbol $. The symbol $ in data 81 is checked against the symbol $ in symbol column 85 of table 84 as indicated by line 91. The corresponding entry in encoded sort order column 83 of table 84 is the number "5". This number is then placed in the final position of sortkey 82 as indicated by line 92.

As can be seen from the foregoing, the encoding process is relatively simple and flexible once the language dependent data files 36 are set up. In addition, the encoding process 33 will not introduce major overhead to the current sorting process or logic. The encoding simply replaces the current case conversion which is performed prior to comparison of two strings during the sorting process. Notice that the encoding process 33 includes case conversion as well since sorting is supposed to be case insensitive.

To give an even better understanding of the advantages and details of the sorting methods described in the previous sections, the contents of the three encoding tables (56, 60, and 84), and the transliteration process involved in the encoding operation is described below in more detail.

For the illustrative embodiments described, the distribution of the encoded sort order values for different characters is depicted below:

(1) value 1 to value 65 for non-alphanumerical characters.

(2) value 66 to value 75 for digits.

(3) value 76 and up for letters defined in the language and transliterated foreign letters.

(4) value 0 for characters that can have but do not have accents.

(5) the values for accents are as follows:

(6) 0, 1 and 2 indicate respectively 1-to-1, 1-to-2 and 2-to-2 encoding.

(7) Ignore is given the value 255 or 0.

More complete contents of the Alphanumerical Character Encoding Table 156, for language 5, which might be the Spanish language, are shown in Appendix E.

More complete contents of the Accent Priority Encoding Table 160, for languages 1 and 5, are shown in Appendix F.

More complete contents of the Non-Alphanumerical Character Encoding Table 184, for languages 1 and 5, are shown in Appendix G.

The contents of the Alphanumeric Character Encoding Table for language 1, which might be the English language, are shown in Appendix D.

One of the advantages of the sorting method of the present invention is the capacity to sort foreign letters. However, since sort orders are only defined for letters within the language's alphabet, a special method called "transliteration" is used to transliterate foreign letters. Examples of the transliteration process of foreign characters for several languages are shown in Appendix C. The concept behind the transliteration process is very simple: characters that do not appear in a language are collated where users of that language might be expected to look for them and in most cases the grouping is based on geometrical similarity.

In somewhat more detail, all the characters defined in ISO 8859/1 will be assigned sort orders even if they do not belong to the user's language. The characters outside the user's language will be sorted according to the following general rules:

(a) Geometrical similarity--some foreign characters may resemble a national character and as a result, they may be sorted together (e.g. A would become A in English).

(b) Phonetic similarity--some foreign letters may sound identical or similar to a national letter (even though they look different) and then they may be sorted together (e.g. would become A in Swedish; .beta. would become ss in English).

The concept used in transliteration is incorporated into the encoding tables when language dependent data files are created. This means the proposed sorting methods include techniques for sortkey encoding as well as transliteration of foreign letters. Refer to Appendix C for the relationship between different languages.

Simplified pseudo-code useful for understanding the implementation of the present invention is included in Appendix A to which attention is hereby directed.

It is believed that the pseudo-code of Appendix A is self-explanatory, but in order to ensure a complete disclosure, flowcharts (FIGS. 12, 13, 14A and 14B) have been included to describe the operations performed by the pseudo-code.

The sections of the pseudo-code of Appendix A are cross-referenced to the corresponding sections of the flow charts of FIGS. 12, 13, 14A and 14B by the reference characters starting with the letter C.

A Glossary of terms used in this document can be found in Appendix B, to which attention is directed. ##SPC1##