At 12:34 AM 12/28/01 -0600, [EMAIL PROTECTED] wrote: >If you want to define text/math, and provide the disappearing parenthesis >and precedence tables and everything, then that's fine, but I don't see >why it should be part of Unicode, anymore than full music rendering is part >of Unicode. It's a higher level protocol. IMO, section 5 should not be part >of a Unicode draft report for that reason.
This opinion is shared by others and the best place for the information in section 5 will certainly be discussed when the current *proposed* draft is being reviewed for advancement *draft* status. In the meantime, I'd like to comment on your analogy. The analogies to full music rendering are not as close as they appear at first glance. If you look at a mathematical, scientific or technical paper you will find substantial amount of mathematical notation appearing as part of ordinary text lines, including, at times, headings and titles, in other words, strings that often are part of databases. (**) The same is not true for music laid out on staff. Secondly, a large subset of mathematical formulae can be expressed very directly in a linear, text-like fashion, even though the remainder do require fairly heavyweight markup to display correctly. Again, this is not strictly analogous to musical notation. The convention proposed in section 5 is clearly a lightweight markup protocol. The disappearing parens in themselves are borderline in that regard - in fact the mechanism is not far removed from some of the complex script cases, where characters may or may not be invisible depending on context. And giving operators some properties is not so remvoced from FRACTION SLASH. However, to be workable, the proposed convention needs subscript and superscript operators, and ultimately a convention of applying certain "decorations" (limits, as well as combining accents) to both individual characters and groups of characters. These are the aspects that most clearly appear to cross the line into the realm of markup protocols. On the other hand, the proposed 'markup' itself consists of the kinds of things that one would use in a plain text fallback, e.g. when communicating an equation by e-mail. One can conclude that the proposed convention is a 'renderable plain text fallback' that happens to cover a large subset of commonly used mathematical notation. It is therefore a very different beast from MathML, which is a full-fledged markup protocol, able to cover practically everything and only barely human readable in source form. As such it occupies a novel middle ground between the plain Unicode (with script rules) and full-fledged markup schemes. A./ PS: Disclaimer: while I am a co-author of the TR, the credits for inventing the scheme described in section 5 belong entirely to Murray Sargent, who will undoubtably have his own things to say about it. PPS: I did not elaborate on why the fact (marked with (**) above) that limited amounts of mathematical notation end up in database strings is significant. The reason is that such strings are ultimately plain text that need to be rendered in the absence of heavy duty markup protocols. A convention that implements its own plain-text fallback has great advantages.