>>>>> "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
(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.
Joachim Schrod Email: [log in to unmask]
``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