RE: support of numbers

From: JFC (Jefsey) Morfin (jefsey@jefsey.com)
Date: Thu May 12 2005 - 22:56:41 CDT

  • Next message: Antoine Leca: "Re: support of numbers"

    On 07:43 12/05/2005, Dean Harding said:
    >I wrote a little app which converts between Ethiopic and arabic-indic (aka
    >0-9) numbers just for the fun of it a while ago. You can check it out
    >here:
    ><http://www.codeka.com/blogs/index.php/dean/2005/02/04/parsing_ethiopian_numbers>http://www.codeka.com/blogs/index.php/dean/2005/02/04/parsing_ethiopian_numbers
    >
    >Do Ethiopian telephones really use ethiopic numbers, though?

    I thank everyone for help! May be can I document a little bit more the need
    for you to understand as it may give ideas. And feed backs.

    The application is to be put into a browser, plug-in or any internet web
    service access panel or used in PADs (private alias directories: your
    internet "phonebook" where you enter the name you want for the IP address
    you want in the language you want and which works everywhere for 36 years
    this year).

    So you may enter the URL 1.707.222.45.67 and get somewhere (preferably on
    the site of the owner of the telephone number). But you may also access a
    documentation center in using its Interface Grid (the directory of its
    canonical[or not] numbers for an information). This is where even
    Kharoshthi numbers can be used (you work on a Kharoshthi document using
    Hans' smart keyboard: you want to call a reference, you will use Kharoshthi
    numbers). The Interface Grids are by nature Hexa (IPv6) but they will
    probably be standardized as decimal and >9 reserved for special plans or
    service characters, like on the phone (#,*, @, etc.) which works with 12
    figures. Except for ISO 10646 Hexa like tables.

    This is why the languages "telephonic" scripts are of importance (there are
    a lot of charsets). In every language including Kharoshthi. The conversion
    Ethiopic to decimal too. Because the canonical IPv6 (Uninum)
    Interfacenumber will be the same (pivotal multilingual information) for
    everyone, but will not be _numbered_ the same by the users.

    Obviously a PAD can also be used and numbers being aliased with tags.

    Let consider that Hans has defined a touch-screen keyboard and he can
    easily switch charsets (we are in dynamic Internet, so better speak
    Internet): he wants to look like a Russian speaking person, using Cyrillic,
    of military background chating in a relax manner on the web and having a
    good scientific background. He will use the corresponding script
    (Cyrillic), language (Ukrainian), regional (Russian), referent
    (Military language) and style (casual) subtags and will call an ISP
    (intelligent service provider) CRC (context reference center) able to
    filter them positively. When he has done that he will select there a
    scientific orientation for his context: for jargon, formulas, quotes,
    ontologies, calendar, jokes, statistics, etc. He will save his langtag with
    the date (in case subtags change definition, like for "CS" in ISO 3166) as
    "HansRu" at a given InterfaceID, which will keep the Interface ID of all
    these elements for him for some additional services. He can also save
    HansRu-one as the context he got on this CRC, but he can go on others for
    more, and possibly add them in HansRu-two, etc.

    With that anywhere he is, he can call HansRu-one and have all the
    information and Word personal dictionary and style parameters entered to
    chat with all the assistance specific to the avatar he wants to play.

    Obviously one sees that the locale notion attached to the computer and
    partly to a region, etc .. will blur and be inserted in the context which
    is attached to the user. For a good understanding: the locale is a software
    part to control your hardware, the context is a brainware part to control
    your software. You can play with locales and you can play with contexts....
    and get conflicts :-)

    I work on the basic technicallities of Contexts for three years. We created
    a national test CRC structure for that. And we start having making big
    "suggestions". InterfaceGrids are probably a very important standardisation
    issue including plug and play functions, e-home, e-city management, etc.
    Another is the dialog with CRCs which is to be quick and fast: direct IPv6
    address is good, but XML :-( ... Tagging is interesting as in fact a very
    simple, pervasive, proven and efficient support system is .... the DNS. You
    enter your personal tag (this permits you to rename the whole Unicode names
    in every languages every day) and you get its canonical InterfaceID on
    every CRC (an Interface ID is like a telephone extension, but there are
    trillons of them, for each use you may have).

    Obviously web services, or applications can use them. Let assume you
    develop in a Chinese environment and never see an ASCII character. You want
    to enter a French langtag for a person of the Versailles area using the
    Universalis Encyclopedia as a language reference writing an administrative
    document. You will enter each of these subtags aa Chinese labels attached
    to the chinese.chinese CNNIC domain name of your CRC's access server (a
    simple smart name evaluation system over the DNS - it saves management and
    permit entries in disorder) were it may know the granularity of Versailles
    from its postcode, or default to France. It will find for you the
    corresponding IP, and the numeric encryption for it. The French receiving
    end will check the numeric langhage encryption and get all the elements
    from its own Latin local CRC tables.

    This works for every "human compatible" exchanges. Let consider two
    webservices dialoguing in e-Spanish (Spanish version for
    inter-human/computer usage, a new language to add to ISO 639-6). The
    specification of the language will permit them to dialog, but the user will
    be able to follow. Now if you interface an OPES (a process which acts on
    the traffic flow - cf. IETF WG-OPES), it will look at the words and will
    call on the CRC when there is word of e-Spanish its context does not know:
    it will add a footing note to explain it.

    jfc



    This archive was generated by hypermail 2.1.5 : Thu May 12 2005 - 23:01:18 CDT