Patent Grant
7996207
Not applicable.
This invention was not developed in conjunction with any Federally sponsored contract.
Not applicable.
Not applicable.
1. Field of the Invention
This invention relates to the arts of computer and information displays for multiple languages, alphabets, and scripts. The invention relates especially to the arts of human interfaces (input, display, output) concerning computer network and World Wide Web addresses in languages which require bidirectional display and presentation.
2. Description of the Related Art
The World Wide Web and the Internet have become everyday technologies in most developed economies, and is now becoming an integral part of the process in developing economies. Its ability to communicate information, both in written form such as web pages, graphic form such as photos and videos, and data form such as extensible markup language (XML), is becoming a key factor to every industry in every country of the world.
However, the current technologies supporting the World Wide Web are “English-centric” due to the roots of the beginning of the Internet being an American and European effort. As such, many of the conventions and “standards” employed in servers, routers, e-mail protocols, etc., employ an English alphabet with English-like syntax. Initially, companies and individuals in non-English countries were able to adopt and use these technologies due to their ability to work in both their native language and English.
It is, though, possible that certain information and concepts cannot be mapped into English from a native language, and thus represents an inability of the English-centric World Wide Web (WWW) to effectively communicate this information and these concepts. Further, the successfulness with which consumers may “find” a business on the WWW depends on their ability to input or select a web address which is logical and rational. If a business has a native language name, there may not be a logical or rational English equivalent. As such, businesses which primarily deal in non-English marketplaces may find their success in “going online” less than optimal given that they must adopt an English domain name.
Unicode's ability to represent multilingual text makes it good candidate for establishing the basis for a domain name structure. Unicode brings not only an encoding framework, but also support handling display requirements such as bidirectional scripts. The collection of Unicode's character equivalences is both desirable, and at times necessary, given Unicode's goal of encoding natural language text. These equivalences, however may present problems in the context of domain names.
Unicode's BiDirectional (Bidi) algorithm may be unsuitable for determining an appropriate display ordering for domain names. Specifically, the Bidi algorithm itself possesses a set of implicit assumptions about the usage of common characters. This set of assumptions may not be applicable to domain names. Domain names use the same repertoire of characters that appear in text. This requires a different algorithm for handling domain names.
The transition from the now ubiquitous monolingual ASCII based domain name system to a truly multilingual extendable system has been long awaited. Indeed, it may have already begun without waiting for standards to be developed. This move brings the goal of realizing a multilingual World Wide Web one step closer. Nevertheless, this transition must be approached cautiously as decisions made today may have long lasting effects. These decisions include the set of characters for constructing names, the base character encoding, and the codepoint transmission protocol.
There are, however, certain constraints that must be observed, regardless of these decisions. For example, domain names that are “legal” today must still remain legal in the new domain name system, otherwise the new system will not receive widespread acceptance. It is impractical to expect a vast overhaul or retrofit of thousands or millions of content servers, domain name servers, and routers in order to support a new, non-backwards-compatible domain name system.
A likely starting point for choosing the allowable set of characters from which domain names may be constructed is to start with the character repertoire available in the well-known Unicode/ISO10646 standard. The range of characters available in Unicode is vast and accommodates most modem written scripts. In contrast to ASCII, it includes scripts such as Arabic, Farsi and Hebrew.
At first glance, extending the current domain name system may not seem to be much of a challenge, given that all that needs to be done is to add more characters to the script. However, unlike ASCII, which only encodes scripts written and displayed in a left-to-right order, Unicode encodes scripts written right-to-left, as well as those written left-to-right. Additionally, in Unicode, it is perfectly “legal” to intermix these scripts, which provides not only for a wider variety of single-language displays, but also for displays of mixed content. However, when these scripts are intermixed, their display may become ambiguous, due to the conflicting directions.
In creating a new domain name system, such ambiguities must not exist. The display of such domain names can not simply be left up to the user or application software, which would certainly lead to confusion.
In order to alleviate this situation, a BiDirectional domain name method and system must not allow for ambiguities in the interpretation, display, or analysis of a BiDirectional domain name. Additionally, this method and system must be both simple to understand, easy to implement, and inexpensive to execute, in order to facilitate its widespread acceptance and use.
Therefore, there is a need in the art for a system and method which allows domain names to be handled and displayed with different (non-English) reading orders. Further, there is a need in the art for this system and method to be readily usable within the currently deployed technologies of the World Wide Web, and compatible with existing methods and systems such as Unicode's BiDi algorithm.
The following detailed description when taken in conjunction with the figures presented herein provide a complete disclosure of the invention.
A multilingual bidirectional domain name is produced by receiving a domain name having characters from at least two character sets with different display orders with just one direction of reading; breaking domain name into labels delimited by a full stop punctuation marks, the labels having an original label display order as encountered from left to right; within a label, resolving display directions of indeterminate display order characters by assigning a strong reading direction left-to-right display order to each indeterminate display order character; subsequently, reordering the characters within each of the labels into a display order using the fully resolved characters while preserving the original label display order and wherein bidirectionality of characters within each label is produced, so that produced the multilingual bidirectional domain name contains at least two different directions of reading across the entire converted address; and, displaying the multilingual bidirectional domain name on a computer display.
In accordance with the objectives of the present invention, a primary goal of a multilingual domain name display and analysis system and method is to unambiguously represent multilingual domain names. Optimally, the multilingual domain name system and method must also:
The present invention is preferably realized as a function or method in computer-executable software for Internet servers, clients, and routing devices. Turning to
Most computer platforms, such as a personal computer, are also equipped with disk interfaces (75) and disks; user device I/O (76) to interface to keyboards, pointing devices, and a display; and a network interface card or device (77) allowing communications to a computer network, wireless network, or the Internet. Some computer platforms, such as personal digital assistants, web-enabled telephones, and Internet appliances may not be provided with all of these components, but in general, the functionality of these components is present in some form.
The computer platform (70) is also typically provided with one or more non-portable, machine-specific application programs (702).
According to the preferred embodiment, the computer platform (70) is provided with a Java interpreter (701), which are freely available for a variety of operating systems and computer platform, and which are well-known in the art.
The remainder of this disclosure is given with respect the logical methods to be realized in computer executable software, and preferably realized in a Java program, applet or servlet.
When domain names are interspersed within natural language text the problem of displaying the text and domain names becomes rather complex. This complexity, however can be managed if the problem is broken into separate and distinct phases. The problem with simply modifying the Unicode Bidirectional Algorithm to accommodate domain names is it makes an already complex algorithm even more difficult to manage.
The essence of the Unicode Bidirectional Algorithm is first to perform contextual analysis on the text and then determine where the boundaries of the directional runs are. The general problem with this strategy is that as technology continues to expand greater and greater demands will be placed upon the bidirectional algorithm to always correctly render any and all textual data causing the algorithm to be in a constant state of flux.
When Unicode performs contextual analysis on text it overrides the static proprieties assigned to some of the characters. Specifically this occurs during the processing of weak and neutral types. Separating this portion of the algorithm from resolving implicit levels and reordering levels greatly extends the applicability of the algorithm. Ideally the analysis of the text should be distinct from the actual determination of directional boundaries.
During the analysis phase, domain names, mathematical expressions, phone numbers, and other higher order data elements are detected. Nevertheless, it is impossible to create an computer-implemented process that can always correctly identify such elements. The real issue is whether or not it is possible to create a computer-implemented process that identifies such elements within some reasonable range of error and under a set of acceptable constraints for the elements themselves.
The determination as to whether a stream contains a domain name is rather straightforward if the domain name is preceded by some special identifier. Specifically, “http://”, “ftp://”, or “telnet://”. When these identifiers are not present, however the ability to recognize a domain name becomes greatly diminished. The authors believe it is unreasonable to force every domain name to be preceded by some special signal. There are many cases where it is inappropriate to specify the protocol. For example, consider the case where a marketing memo specifies the name of some website.
For better understanding of the present invention, following conventions are used in examples throughout this disclosure, as patent disclosures themselves do not lend themselves well to BiDirectional and non-English script text:
This representation is summarized in Table 1, which is the same convention used by Unicode to discuss the input and output of the Unicode Bidirectional Algorithm.
The richness of characters available in Unicode is certainly an asset when used to encode natural language text. Nevertheless, this richness is something that is not necessarily desirable when encoding domain names. The various ways in which characters can be constructed in Unicode, both “precomposed” and “decomposed”, makes the representation of domain names unnecessarily complex.
This complexity presents two significant problems for encoding domain names: domain name registration and domain name equivalence. Historically, these have not been a problem, because it made no difference whether the registration of a domain name was based upon characters or codepoints. In ASCII, there is no distinction between characters and codepoints, however in Unicode such a distinction becomes necessary at times.
In Unicode, characters that contain diacritic marks may be represented in two ways: “precomposed” form and “decomposed” form. Characters in precomposed form are represented by a single codepoint, while characters in decomposed form are constructed from multiple codepoints.
For example, the Latin capital letter “u” with diaeresis and acute can be encoded in three different ways (10, 11, 12) in Unicode, as shown in
This has a significant impact on the clear representation of data and especially for domain names. If domain names are registered by characters and not by codepoints, then domain name servers and/or client systems will be required to perform some form of normalization.
Alternatively, if domain names are registered via codepoints and not by characters, then normalization becomes a non-problem. On the other hand, it forces the registration of multiple names (equivalent encodings) that really represent the same name.
Further complicating matters is the fact that Unicode also encodes some characters that are merely glyph variants of other characters. This situation also requires some form of normalization. For example, the two character sequence “fi” may be represented in two ways (20, 21) in Unicode, as shown in
In a first aspect of the present invention, a method is adopted in which only decomposed characters are used in cases where there are no corresponding precomposed characters. This significantly simplifies and facilitates the task of determining name equivalence, as each domain name has a unique representation under this scheme.
In a second aspect of the present invention, characters which are glyph variants of other characters (compatibility characters) are not allowed to be used in domain names. While at first this may seem too restrictive, it is nothing more than an artificial restriction. In reality, there is no need for compatibility characters, as domain name distinction or equivalence is not based upon visual appearance. Further, these characters are unnecessary for legacy data conversion as they are encoded in ASCII now.
In a third aspect of the invention, control codes are excluded from the new multilingual domain names as they currently are today. These include the bidirectional controls, as well, such as LRE, LRO, LRM, RLE, RLO, RLM, and PDF. The purpose of these controls is to override the behavior of Unicode's Bidirectional Algorithm. In most situations, Unicode's Bidirectional Display Algorithm produces acceptable results when rendering natural language text. The use of these controls is only required in the rarest of situations, and thus their elimination outweighs any potential benefits.
Naturally, the set of allowable domain name characters must expand to include Arabic and Hebrew letters, however Unicode has many codepoints for the Arabic writing system and the Hebrew writing system. Not all of these code points are required in the context of domain names.
In another aspect of the present invention, a number of Arabic characters are safely excluded from multilingual domain names, including the Arabic presentation forms, UFB50-UFDFF and UFE70-UFEFC. It is safe to exclude these characters, as they only represent ligatures and glyph variants of the base nominal Arabic characters. Additionally, the Arabic points U064B-U0652, U0653-U0655, and U0670 may also be excluded. In most cases, the Arabic points are only used as pronunciation guides. If the points were to be included, then names that differed only in their use of points would be treated as if they were distinct and different names. This is not unlike the English homonyms “read” and “read”, which are ambiguous. Removing the Arabic points eliminates such problems, with the understanding that not every Arabic word would be able to be uniquely represented.
Further, the Koranic annotation signs U06D6-U06ED can also be eliminated from domain names, as they are not used to distinguish one name from another.
In Hebrew, the cantillation marks U0591-U05AF and Hebrew points UFB0-U5C4 are preferrably excluded from multilingual domain names, as they are predominately used as pronunciation guides and for indicating the underlying structure of text. Additionally, the Arabic and Hebrew punctuation characters are also excluded from domain names, as they are currently not permitted or used in domain names. Table 2 summarizes the list of acceptable Arabic and Hebrew characters.
Unicode's ability to intermix the varoius script systems of the world makes the creation of multilingual documents no more difficult than the creation of monolingual documents. This new found freedom, however does come with a cost. When various script systems are intermixed, their display may become unclear.
Unicode provides an algorithm for determining the appropriate display order given an arbitrary sequence of characters in logical order. The algorithm is based upon a set of implicit heuristics along with a set of explicit control code overrides. These control codes are used in cases where the implicit rules do not yield an appropriate display order.
One may naturally assume that since Unicode characters are going to be used in domain names, then Unicode's Bidirectional Algorithm should also be used. Upon closer examination, it becomes apparent that this approach or assumption is inappropriate. The input to Unicode's algorithm carries with it a set of assumptions. The primary assumption being that the input is natural language text in general. This assumption, however is not necessarily true in the case of domain names. A domain name does not resemble a paragraph of multilingual text. So, different assumptions regarding the content of a multilingual domain name must apply. This contextual difference causes several problems when one attempts to apply the Unicode Bidirectional Algorithm to domain names.
The first problem to be encountered is the use of the full stop character, U002E, within domain names. When a full stop occurs in natural language text, its purpose cannot be immediately determined. The meaning of the full stop is dependent upon the context in which it is used. It may indicate the end of a sentence, an abbreviation, or even a floating point number, such as specified in rules W4 and W5 in Unicode Standard Annex #9.
When a full stop, however, is present in a domain name, its meaning is clear. The meaning of the full stop never varies across domain names. The full stop always serves to separate a domain name into its individual parts or “labels”. Furthermore, the full stop establishes the hierarchy of the individual labels. In domain names, there is a strict hierarchy regarding the ordering of the labels. The most general part of the domain name is always the rightmost label, while the most specific part of the name appears as the leftmost label (e.g. “subdomain” labels). This requires a domain name to be read and interpreted in a general left-to-right, English-like direction.
When the Unicode Bidirectional Algorithm's rules are applied to text, it is done on a per paragraph basis. Each paragraph is rendered independently of each other. Unfortunately, when the Unicode Bidirectional Algorithm is applied to domain names, each domain name label is not rendered independently of the others, and as such, each domain name label may influence the rendering of the others. To solve this problem, the method of the present invention implements the full stop character as if as if it were the start of a new paragraph in the context of domain names. Additionally, each domain name is rendered in an overall left-to-right reading direction so as to preserve domain name label hierarchy.
The Unicode Bidirectional Algorithm determines the general reading direction of a paragraph in one of two ways. The first method is based upon a higher order protocol explicitly stating the reading direction; the second method makes use of an implicit rule whereby the first strong directional character determines the overall reading direction. In this context the term “strong” indicates a character that is either a left-to-right character or a right-to-left character. This implicit rule, however causes problems for rendering domain names, as shown in
The first display (30) of
Some may argue that if the overall reading direction is known, in this instance right-to-left, then the hierarchy of the individual labels can be determined. This statement is not true in multilingual domain names, however.
In many cases it is impossible to tell the overall reading direction by merely looking at the output. It turns out that it is impossible to obtain the same output “display order” given two distinct inputs in logical order. In this example, the “normal” input (30) and an alternative input (31) produce the same output or display (32). In this case, the most specific part of the name of the “normal” input (30) “ABC”, while in the alternative input (31) is “bm”. This does not indicate that there is a flaw in Unicode's algorithm, rather it only further illustrates the impact of the assumptions concerning the intended use of the Unicode Bidirectional Algorithm.
Normally, in natural language text processing, this is not a problem given that the two orderings can be distinguished by their physical justification on the screen, either right or left. This factor, however, is not available to domain name displays. When a domain name appears in printed text, there is no generally accepted way to indicate the overall reading direction.
Nonetheless, some may argue that if the entire domain name is in Arabic, then the label hierarchy should be reversed. The problem in adopting this strategy occurs when the entire domain name is not from the same script, as is the case in this example. The method of the invention provides a more desirable multilingual output (4) as illustrated in
One might assume that Unicode's Bidirectional Algorithm may still be appropriate if it is run independently on each of the individual labels. This strategy also presents problems, however. The problem with this approach involves the use of the hyphen-minus character “−”, U002D. In the Unicode Bidirectional Algorithm, the hyphen-minus is assigned to the European Terminator character class. Unfortunately, this causes the character to behave as if it were an European numeral when adjacent to European numerals, as specified in rule W5 in Unicode Standard Annex #9.
This behavior may be acceptable when processing natural language, but is unacceptable when processing multilingual domain names. In multilingual domain names, the predominant usage of the hyphen-minus is as white space, and not as an European terminator, as illustrated in
Yet another problem occurs when an individual label contains characters with varying directions. In this situation, the reading order of a label may become ambiguous, as illustrated in
Further according to the present invention, multilingual domain name registration is made in logical order. This policy is consistent with how bidirectional data is generally stored in files today. If the Unicode Bidirectional Algorithm is permitted to be used for the display of domain names, then there may be situations when a domain name can not be resolved even when it appears to be entered correctly. One possible solution to this situation is to register multiple logical names that yield the same display order. However, according to the method of the invention, a better approach is provided which eliminates this many-to-one relationship. Using the method of the invention, each display order is mapped to one and only one logical input, and each logical input is mapped to one and only one display output. This policy comes with some associated cost, however. There maybe cases where the reading may seem unnatural. It is believed, however, that this will occur infrequently and that the benefits outweigh any potential misreading.
The method of the invention is divided into two phases: inferencing and reordering. Inferencing resolves the direction of indeterminate characters, such as the fall stop or “dot”, hyphen-minus, Arabic numeral, and European numeral. During this phase each character is assigned a strong direction, either left or right. The reordering phase takes the fully resolved characters and generates a display ordering for them.
The inferencing phase is accomplished in several passes. In the first pass Arabic and Hebrew letters are assigned the right-to-left direction, while fall stops and other alphabetic characters are assigned the left-to-right direction. The next set of passes resolves the directions of digits.
There are two rules for resolving the direction of Arabic and European numerals. All Arabic numerals are assigned the right-to-left direction. European numerals are assigned the left-to-right direction, unless the European numeral is surrounded by right-to-left characters (Arabic or Hebrew letters), in which case it takes the right-to-left direction. This is accomplished in two passes -a forward pass and a reverse pass.
The final set of passes resolves the directions of hyphen-minus characters. There are two rules for the resolution of hyphen-minus characters. All hyphen-minus characters become left-to-right, unless the hyphen-minus is surrounded by characters whose direction is right-to-left in which case the hyphen-minus becomes right-to-left. This is the same resolution as digits, but occurs after digit resolution. At this point each character in the domain name has a strong direction.
According to the preferred embodiment, the resolution of digits and letters makes use of a few simple data structures. A digit accumulator holds a sequence of European or Arabic numerals. A character stack holds Arabic letters, Hebrew letters, and sequences of digits. A mode variable keeps track of the current direction.
Further, the preferred embodiment makes use of a few simple operations on these data structures, including a “clear” operation, which outputs each digit from the digit accumulator, then outputs each character from the character stack, and finally outputs the current character. After this operation, the digit accumulator and the character stack are left empty.
An “empty” operation outputs each character from the character stack, then outputs each digit from the digit accumulator, and finally outputs the current character. After this operation, the digit accumulator and the character stack are empty.
A “push” operation places the contents of the digit accumulator onto the character stack, and then pushes the current character onto the stack. After this operation the accumulator is empty.
An “accumulate” operation appends the current character onto the digit accumulator.
The preferred embodiment of the inventive method for resolving letters and digits is disclosed in pseudo-code in Table 3.
The bidirectional domain name display method shown in Table 3 converts a string of characters in logical order to a string of the same length in display order. In fact, the method is its own inverse, e.g. A(A(x))=x. Hence, this method is a one-to-one function. To further support this rationale, there are several indicators of the behavior of the method which are true of such types of methods. First, it is obvious that the method loses no characters, so the output is a string of the same length as the input string. Second, all left-to-right runs, including full stop and certain hyphen-minus characters, are preserved in exactly their original positions within the resultant string. Third, all right-to-left runs are permuted within their own run. No characters “leak”, “flop” or move to another run and the right-to-left runs are preserved in their same order. Finally, the right-to-left runs are reversed (approximately).
The nature of reversing right-to-left runs requires further explanation as the numerals (Arabic and European) complicate the matter.
This method can be used to accommodate two different groups of domain name creators. One group knows what they want to register, but they are unsure how it will be displayed. On the other hand, there are creators who know what they want to see displayed, but are unsure what logical sequence of characters should be registered. This single universal method addresses both of these situations, which eliminates the need for specialized individual method.
The disclosed logical methods are preferably realized in software executable by a web server, such as a Java servlet, or by a web client, such as a Java applet. One such embodiment is provided in the Table 4.
It will be readily apparent to those skilled in the art, though, that alternate embodiments such as coding using alternative software languages and methodologies incorporated into or associated with products such as web browsers, router firmware, etc., may be made without departing from the spirit and scope of the invention. As such, the scope of the invention should be determined by the following claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4507734 | Kaldas | Mar 1985 | A |
| 5539661 | Nordenstam | Jul 1996 | A |
| 5572727 | Larsson et al. | Nov 1996 | A |
| 5784069 | Daniels et al. | Jul 1998 | A |
| 5793381 | Edberg et al. | Aug 1998 | A |
| 5883986 | Kopec et al. | Mar 1999 | A |
| 5889481 | Okada | Mar 1999 | A |
| 5929792 | Herriot | Jul 1999 | A |
| 5946499 | Saunders | Aug 1999 | A |
| 5946648 | Halstead et al. | Aug 1999 | A |
| 6055365 | Tye | Apr 2000 | A |
| 6070179 | Craft | May 2000 | A |
| 6151624 | Teare et al. | Nov 2000 | A |
| 6204782 | Gonzalez et al. | Mar 2001 | B1 |
| 6243701 | Shih et al. | Jun 2001 | B1 |
| 6275789 | Moser et al. | Aug 2001 | B1 |
| 6324500 | Amro et al. | Nov 2001 | B1 |
| 6397259 | Lincke et al. | May 2002 | B1 |
| 6438516 | Davis | Aug 2002 | B1 |
| 6493735 | Kumhyr | Dec 2002 | B1 |
| 6611845 | Dockter et al. | Aug 2003 | B1 |
| 6738827 | Abir | May 2004 | B1 |
| 6937975 | Elworthy | Aug 2005 | B1 |
| 6944820 | Feinberg | Sep 2005 | B2 |
| 7120900 | Atkin | Oct 2006 | B2 |
| 7293229 | Feinberg | Nov 2007 | B2 |
| 7366977 | Chokshi | Apr 2008 | B2 |
| 20020030689 | Eichel et al. | Mar 2002 | A1 |
| 20020143521 | Call | Oct 2002 | A1 |
| 20020156688 | Horn et al. | Oct 2002 | A1 |
| 20020156888 | Lee et al. | Oct 2002 | A1 |
| 20030115040 | Jun 2003 | A1 | |
| 20040039996 | Flam | Feb 2004 | A1 |
| 20060080641 | Taylor et al. | Apr 2006 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20030110021 A1 | Jun 2003 | US |
