[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 [EMAIL PROTECTED] 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: <[EMAIL PROTECTED]>
