Date: Fri Sep 27 2002 - 11:52:28 EDT
[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
>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
>that remark may prejudice people from taking an interest in helping to
>develop the idea because of a political dimension of going against the
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 firstname.lastname@example.org list somewhere where you
>>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.
>I'm going to refrain from commenting on anything beyond the markup issues
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
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
>literary works, yet for a comprehensive system which can include the
>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
>Actually, I was rather hoping that, with your specific interest in
>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
>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
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
This archive was generated by hypermail 2.1.5 : Fri Sep 27 2002 - 12:48:19 EDT