Re[2]: Marks

From: Dmitry Turin (
Date: Thu Sep 27 2007 - 02:22:44 CDT

  • Next message: Dmitry Turin: "Re[2]: Marks"


    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


    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.

    PV> None of your proposals
    Please, divide your critique of proposals to different letter.
    And write registry #1 ... , #2 ... , #3 ... for each of proposals

    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

    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.
    Plug-in for computer is necessary for Unicode II.

    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
    "-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.

    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)
    HTML6 (6.4.1)
    SQL4 (4.3.0)
    Computer2 (2.0.3)

    This archive was generated by hypermail 2.1.5 : Thu Sep 27 2007 - 02:36:54 CDT