From: Dmitry Turin (unicode20@narod.ru)
Date: Thu Sep 27 2007 - 02:22:44 CDT
Philippe,
When i only look at your letter,
i knew much of its context by following features:
(1) letter is very big
(2) letter is not structured
---general
PV> You are mixing everything in your message, every
PV> concept, and attempting to completely remove all the abstractions already
PV> performed and the intended goals.
I'd like to listen registry (list) like #1 ... , #2 ... , #3 ...
PV> Not only your various proposals to the list won't work as intended (you
PV> forget MANY things)
Read above.
PV> Not every concept needs to be formalized at the plain-text level.
Similarly.
PV> None of your proposals
Please, divide your critique of proposals to different letter.
And write registry #1 ... , #2 ... , #3 ... for each of proposals
separately.
PV> By trying to mix every possible concept into a single merged layer
Not "every", but "necessary": please read my argumentation attentively.
PV> you create a havoc
Ortodoxness. No more. Arguments are necessary.
PV> Base your choice
PV> of format according to the use of the text
Please, critisize my arguments:
ecomonization of mark-place, simplification of comparison
---your objections
(1)
PV> won't be accepted (you loose all interoperability
PV> features)
We can propose new version of Unicode (e.g. Unicode II, UTF-8 II).
PV> your encoding completely changes the way to handle text (by
PV> making the text only parsable through contextual rules
Agreed (about "contextual rules").
PV> None of your proposals will even work with existing font technologies.
Agreed.
Plug-in for computer is necessary for Unicode II.
(2)
PV> impossible to perform without having to parse the WHOLE
PV> text where the substring is extracted, FROM THE BEGINING)
No, i.e. "whole text" is not in deal.
Both prefix-bytes act only to one word
(maybe it will be convinient to you to think,
that prefix-bytes is _only first letter_ of word).
(3, markup languages)
PV> These notations you propose are ALREADY implemented using other opper-level
PV> layers or standards
(1) I already have wrote in http://unicode2.chat.ru/site/unicode2/en/author/index_eng.htm
"-So, we have proved, that all, what you offer to make on your a-a-a...
Fortran, is possible to make on assembler.
-First, I know this without you, second, speech was not about that."
(2) I also have wrote argumentation of my proposal in my first letter
in thread.
PV> You are trying to redefine a new rich-text format
Rich-text format is markup language, as i said above.
PV> right approach is to separate the problems
Already done.
One problem is graphic images (font), second problem is designation of a letters (coding).
Both problem are bind.
PV> everything else in other upper-layer
Not in upper-level: read argumentation.
PV> not on their rendering.
"semantics of text elements" and "rendering" are bind things.
One don't exist without second.
(4)
PV> your proposed characters just an unneeded
PV> pollution complicating the implementation of the many other upper-layer
PV> protocols (many of them standardized too!)
If my proposals will be accepted,
some features of markup languages will have possibilities,
which duplicate possibilities of plain text _in encoding_ Unicode II
(let's designate these features of markup languages as X).
So we have the following matrix:
UnicodeII other-encoding
X dup -
non-X - -
And this duplication in markup languages is
(*) deal of markup languages itself
(*) does not break my argumentation for prefix-byte
[ecomonization of mark-place, simplification of comparison]
---back questions
PV> that are even
PV> embedding concepts in unlimited levels and on unbound distances
Rephrase please, i don't understand.
PV> making things like safe extractions of substrings within text
What is "extractions of substrings within text" ?
---about my person
PV> Unicode, which concentrates on semantics of
PV> *text-only* elements
I think similarly.
PV> many errors like your usage of "byte" instead
PV> of code point
Remember about non-europen people and (human) language problem:
i'm writing to chinise,etc also.
PV> Unicode standard does not mandate a single binary representation
But de-facto it creates binary representation standard.
---thread missmatch
PV> what would be the meaning of a fraction of other mathematical
PV> formula within the designation of a domain name? or in the designation of a
PV> variable name or API name in a computer language?
Answer is directed into suitable thread.
PV> If you want to transport text documents that include some advanced features,
PV> use some other formats than just *.txt files: OpenDoc for example is based
PV> on XML and offers such capabilities. If you want an exact rendering, use
PV> PDF.
Bad comparison characteristic of XML and PDF
(i will not develop this question, because it's off-topic).
Dmitry Turin
Unicode2 (2.1.0) http://unicode2.chat.ru
HTML6 (6.4.1) http://html60.chat.ru
SQL4 (4.3.0) http://sql40.chat.ru
Computer2 (2.0.3) http://computer20.chat.ru
This archive was generated by hypermail 2.1.5 : Thu Sep 27 2007 - 02:36:54 CDT