Re: Keys. (derives from Re: Sequences of combining characters.)

From: Peter_Constable@sil.org
Date: Fri Sep 27 2002 - 11:52:28 EDT

  • Next message: Tex Texin: "Re: glyph selection for Unicode in browsers"

    [This is entirely off-topic.]

    On 09/27/2002 06:24:27 AM "William Overington" wrote:

    >Yet what indication whatsoever do you have that I ignore what you write?

    The fact that you have been given recommendations from several people on
    this list not to invent new markup conventions but to take advantage of the
    existing, state-of-the-art technologies for this purpose, yet you have
    consistently rejected those recommendations.

    >I do not always agree with you,

    I doubt there's anyone on this list that always agrees with me (I certainly
    hope not; after the passage of time, I often don't agree with myself :-).

    >>it has no existing software support,
    >>and nobody but you has any interest in it.
    >
    >You have no basis whatsoever for claiming that nobody other than me has
    any
    >interest in it.

    It's only a claim, a hypothesis that I happen to consider to have enough
    probability of validity to make me feel confident in stating in a public
    forum. Of course, I may be wrong.

    >Maybe you are not interested, maybe some people you know
    >are not interested, yet I feel that it is unfair for you to make such a
    >statement without evidence when writing from an established organization
    as
    >that remark may prejudice people from taking an interest in helping to
    >develop the idea because of a political dimension of going against the
    tide.

    I feel there is evidence: take a look at any serial publication related to
    the software industry from the past three years and look for references to
    XML. It comes up again and again and again. The evidence very strongly
    points in favour of XML if one is needing a markup convention for some
    protocol. There may well be some situation in which XML isn't appropriate;
    e.g. one might have valid reasons for wanting to maintain a binary file
    format as the native storage representation for a word-processing or
    spreadsheet app. But if one is going to use a *character*-based markup
    convention, I think you'd be hard pressed to come up with good reasons at
    this point for using something other than XML.

    >>Perhaps there is an inventors@eccentrics.com list somewhere where you
    might
    >>find greater interest in your ideas than here.
    >
    >That is unfair of you.

    If I offended, then I apologize. I merely wished to suggest that your ideas
    regarding markup are what I think the vast majority on this list would
    consider eccentric, and to also suggest that it's all off-topic for this
    list and really should be taken up elsewhere.

    >You even stated in the same post.
    >
    >quote
    >
    >I'm going to refrain from commenting on anything beyond the markup issues
    >
    >end quote

    And I believe I did so.

    >The topic of keys generally which I have introduced is potentially a
    >far-reaching development in the application of markup in Unicode based
    >systems. My own comet circumflex system may be highly useful in business
    >communications and distance education. I am happy to respond to questions
    >and to consider documents which people suggest.

    But please, not on this list. The is not the comet circumflex list.

    >XML exists and it uses U+003C in a way that makes using U+003C with the
    >meaning LESS-THAN SIGN in body text intermixed with markup sections
    awkward.

    Not significantly so, as evidenced by the fact that many have needed to
    represent the character "<" within content yet this has not impeded the
    widespread -- near ubiquitous -- adoption of XML.

    >That feature of XML may not matter for situations involving encoding
    simply
    >literary works, yet for a comprehensive system which can include the
    U+003C
    >character with the meaning LESS-THAN SIGN in body text and in markup
    >parameters, it does not suit my need.

    Then I think you're making decisions about design of a protocol using the
    wrong criteria.

    >Actually, I was rather hoping that, with your specific interest in
    languages
    >that you would have wished to have a try at using the comet circumflex
    >system as one of the features of the comet circumflex system is that it
    >could be used with minority languages as easily as with the major
    languages
    >of the world.

    Actually, one of the things that I chose *not* to comment on in the
    previous message was the very significant issues the comet circumflex
    system raises in relation to internationalisation and localisation. As
    someone else pointed out, your system has a problem in that a parameter
    such as "London" needs to be localised. There are a range of
    internationalisation issues that your system doesn't address. It isn't
    always safe to assume that one can define a matrix statement that can be
    translated into multiple languages and into which parameter strings can be
    inserted; issues such as grammatical concord may be a problem. I don't want
    to get into such a discussion (especially on this list). My point is, I see
    many potential problems in terms of multilingual application of the system.
    Also, the users I support are not dealing with text involving a set of
    short, pre-defined messages, so this system isn't all that relevant for my
    work.

    - Peter

    ---------------------------------------------------------------------------
    Peter Constable

    Non-Roman Script Initiative, SIL International
    7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
    Tel: +1 972 708 7485
    E-mail: <peter_constable@sil.org>



    This archive was generated by hypermail 2.1.5 : Fri Sep 27 2002 - 12:48:19 EDT