Re: proposal for a "Standard-Exit" or "Namespace" character

From: Dennis Heuer (dh@triple-media.com)
Date: Mon Apr 13 2009 - 20:20:15 CDT

  • Next message: Doug Ewell: "Re: proposal for a "Standard-Exit" or "Namespace" character"

    On Mon, 13 Apr 2009 17:46:17 -0700
    "Tex Texin" <textexin@xencraft.com> wrote:

    > It would also create problems to now have commands in Unicode which would
    > potentially interact or conflict with higher level formatting commands.
     
    you show up a deeply rooted logical error. those standards are mainly
    existing because there was no alternative (for the initial purpose.)
    however, dealing with this hen and egg problem is fairly easy. the HTML
    crew can handle the ambiguity itself by insisting on a default
    behaviour and providing an attribute the next update. it will spread
    fast and widely, as always in the world of HTML.

    > More importantly there are international standards for formatting text
    > called markup languages, that are much more powerful than a small set of
    > control character commands would be, and which coexist quite well with
    > Unicode encoding and are portable.
    > Given the existence and wide support for HTML, etc., the case for such
    > commands in Unicode is extremely weak.

    the main problem with 'international standards' (don't understand this
    argument. the international character-set standards didn't hinder the
    people behind unicode, did they?) is that they are complex, bloated,
    many, and not easy to parse. this is especially true in respect to small
    editors and ***plain text files***. i was very verbous on this, which
    makes me wonder why it wasn't read. what the heck HTML has to do in a
    plain text file (say a shell script)?? this is also the reason why
    common wiki or blog systems stayed away from including HTML but
    'invented' (felt forced to find) an own, short form of writing
    formatting rules. as you can imagine, if you think more deeply about
    it, HTML is not the solution to the problem, be it a standard or not.
    this also relates to ISO-2022 being a dead fish, which doesn't
    astonish me a bit.

    unicode shall not grow into a meta language. the only formatting rules
    (commonly used and most neccessary also in the explained cases where
    they are still missing) to be put into unicode are those which stand
    for themselves or act as on/off-switches. not more or less. in case of
    font size, this means that there are keys for most used sizes and steps
    like +1pt, +2pt, +5pt, and +10pt. that's it. no meta-programming
    neccessary. or, do you consider ODT to be used instead of this? explain
    that to a gnomepad, emacs or wikipedia user.

    many thanks for reading,
    dennis



    This archive was generated by hypermail 2.1.5 : Mon Apr 13 2009 - 20:22:17 CDT