>>>>> "MH" == Martin Hensel <[log in to unmask]> writes:

>> These paragraphs made quite clear that the author didn't know a
>> thing about TeX constraints (and is erroneous about space handling
>> in HTML and XML as well). Obviously somebody who is new to
>> technical details of existing markup languages.
>>
>> So the probability to find something worthwile in the rest of the
>> text was not high enough to spend the time reading further.

MH> Could you please explain to me, where I'm wrong with HTML and XML?

You complained that TeX is inconsistent in its space handling. You
mentioned in your paper the example of leading spaces in lines, used
for indentation, that one can do with HTML/XML/other programming
languages, but not with TeX.

 (1) At this moment, i.e., in the first two paragraphs of your
     content, you mixed already your topic. You didn't write about
     author interface any more, but about programmer's interface.

 (2) In the programmer interface, it's very easy to ignore spaces at
     all; many TeX programmers do it. So the problem is avoidable
     there.

 (3) In author-land, where I can see your problem actually, HTML has
     very similar problems to TeX. White space is collapsed to one
     space usually, but sometimes it's ignored, sometimes it's output.

     Now, I'd say that more TeX users understand TeX's space
     processing, than HTML users understand HTML space rules. Not
     least that's because in the HTML arena (a) one has to look for
     the processors, i.e., the browsers, and their space handling; and
     (b) one may want to look at the definition.

     Concerning the browsers: they simply don't implement the standard
     correctly. My staff regularily has to reject designs from
     so-called "Web designers" who rely on Dreamweaver and don't pay
     enough attention to browser-specific problems.

     Concerning the definition, HTML is still an SGML application and
     thus includes all the RS/RE cruft. Not made easier by the
     definition of block vs. in-line elements. IMO that implies that
     few people do really understand the formal definition. (If you
     haven't appreciated that yet, buy the SGML Handbook by Charles
     Goldfarb and wonder about the complexity lawyers can introduce
     when they define formal languages.)

 (4) XML doesn't collapse white space. That's the job of the
     processor. E.g., XSLT has even special syntactic facilities to
     handle elements where it should be ignored (sometimes ;-) and
     where it shouldn't.

And the quotations in your email didn't address the problem in your
document at all. Yes, you quoted HTML space handling, but no, you did
_not_ show the differences to TeX where HTML is supposed to be more
"regular" and easier to handle for the user. Yes, you quoted the XML
white space definition, but no, you did _not_ address white space
handling in PCDATA.

Btw, you haven't even mentioned the real ideosynchrasies of TeX, like
handling of ^^0d. That brings me to the real issue: Do you actually
know that most of TeX's white space handling happens before
tokenization, i.e., before the programming starts at all? You do know
the basic principles of the TeX macro proces, do you? You did
understand that some people on this list have their doubts and that
they demand from you that you show your basic knowledge before they
look at your proposals?

I hope that I didn't trump on you too much. To ease your feeling, I'll
refrain from further contributions to this thread -- as I've said, IMO
the newsgroups are a better avenue to find user feedback about your
ideas than this mailing list.

Cheers,
        Joachim

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod                                  Email: [log in to unmask]
Roedermark, Germany

        ``How do we persuade new users that spreading fonts across the page
        like peanut butter across hot toast is not necessarily the route to
        typographic excellence?''                       -- Peter Flynn