W3C home > Mailing lists > Public > w3c-math-erb@w3.org > July 1996

Re: html markup of previous sample

From: Ka-Ping Yee <s-ping@orange.cv.tottori-u.ac.jp>
Date: Mon, 08 Jul 1996 11:16:53 +0900
Message-ID: <31E06F95.5386884D@sse.tottori-u.ac.jp>
To: Ron Whitney <RFW@math.ams.org>
CC: W3C Math ERB <w3c-math-erb@w3.org>
The following is how i would mark up the example posted by Ron Whitney
using MINSE.  Some notes about Ron's markup and what is done here are
included first (where i refer to Ron's points, i mean the ones in the
more recent HTML posting unless otherwise specified).

------------------------------------------------------- notes on example

1.  Ron mentioned his use of <mo> </mo> to indicate that the entity
    (&nu; \cdot \nabla) is an operator (Ron's point 4).

    With MINSE, i think this won't be necessary.  The "oper" compound
    indicates operator application and implies that its first argument
    is an operator, much like "apply" means function application, while
    implying that the first argument is a function.  "oper" typically
    may be rendered just by placing its two arguments side by side.

    This lets you write things like "(D^2 + 3D + 1)f" where the D is
    the derivative operator.  The convention for parentheses which
    is described in Bruce's current proposal makes it impossible to
    do this without special provisions like "&FunctionApplication;",
    as i previously noted.

2.  Note that what Ron has as (&nu; \cdot \nabla) i marked up as
    (?nu? .dot 'Grad), assuming that the \cdot meant "dot product"
    and that the \nabla meant "gradient".  Similarly, i have assumed
    that &otimes; means a tensor product.  If, as i suspect, i have
    chosen the wrong meanings because i have no expertise in the
    subject of this paper, these can be replaced with the appropriate
    compound names.  

3.  Ron also mentioned his use of &FunctionApplication; to indicate the
    application of the new operators "div" and "curl", and possibly to
    indicate the application of "max" and "lim" (Ron's points 5 and 9).

    With MINSE we don't need to worry about this ambiguity because we
    can just add context definitions for "div" and "curl".  Here the
    name i chose reflects my assumption that "div" means "divergence".

4.  In many situations multiple comparisons are written in a chain,
    which happens here under the "max" compounds with "0 <= i <= T".
    How does your notation deal with this and the issue of operator
    associativity?

    I ran up against this problem of serial and chained operators
    and solved it before the prototype went up on June 2 by placing
    all the relational operators on the same precedence level with
    the special associativity "chain", allowing the definition of a
    "comparison" compound which can infer that "0 <= i <= T" means
    "(0 <= i) and (i <= T)".

5.  Ron mentioned that "R" is used for two different meanings (his
    point 1 in the TeX posting).  There is no such ambiguity if you
    use "'Real" to mean the reals and "R" to mean a named variable.

6.  With regard to Ron's point 2, i didn't know the meaning of D&nu;/Dt,
    but if i knew that it was a special kind of derivative i could have
    defined a new compound to take care of it.  For now i have just
    treated the D as the name of an operator.

7.  A new compound "funcdep" is defined to indicate the "functional
    dependence" which Ron mentioned (his point 3 in the TeX posting).
    I don't know what it means to place "t" as a prescript in front of
    the pair "?nu?;1, ?nu?;2", so i was not able to choose a more
    meaningful compound name.  The new compound is attained with a
    context definition.

8.  As with Ron's example, alignment is left for later (Ron's point 3).

9.  Ron marked up "absolute value" using &leftvert; and &rightvert;
    (Ron's point 7).  How is the grouping ability of these symbols
    declared?  I used an absolute-value compound  because i thought
    it was more appropriate here.

    The ability to write things this way is only a convenience, but
    a provision for bracketing constructs shouldn't be hard to add
    to MINSE's notation parser.  This would let you define new
    bracketing constructs easily in the notation definition, so
    that you could write [0, 'inf) if you wanted to.

10. The ad hoc matrix multiplication operator (Ron's point 7 in the
    TeX posting) is again handled by simply making a new compound.
    If it were used frequently, the author could just add a new
    binary operator to the notation definition and the precedence
    and associativity would be defined there.

    In Ron's markup, i'm not at all sure what the consequences of
    an operator with undefined precedence would be (Ron's point 11).

11. On the very last line of Ron's markup we've got

    &sum;_{i,j}a_{ij}b_{ij}

    This doesn't seem to make it clear that {ij} is to be a double
    subscript as opposed to an identifier "ij" or something else.
    With MINSE i wrote "a;i;j" because the index operator ";" is
    left-associative and can indicate that "a" is indexed with "i"
    and then indexed with "j".  Alternatively, "a" could be indexed
    with the pair "i,j" using the comma operator.

    Notice also that here Ron uses the underscore to represent
    both the conditions on the summation and the indices on the
    variables.  I'm not certain that this distinction can always be
    unambiguously made; an index operator makes this much clearer.

12. Superscripts abound in this example, and as Ron noted they have
    the various meanings of product and index (Ron's point 5 in the
    TeX posting).  In the cases where they indicate an index, as in
    L^1 and C^\infty, they are so distinguished with the compound
    "upidx".  The lack of a more meaningful name is again due to my
    lack of experience.

13. Parens are also used for all sorts of meanings in this example
    (Ron's point 6 in the TeX posting), and i think it's impossible
    to tell the difference between the interval "(0,&infinity;)" and
    the pair "(&nu;_1,&nu;_2)" the way Ron has it marked up.  It is
    also very unclear when the parens indicate function application,
    as in "&nu;^&epsilon;(x,t)".

    This is all distinguished in the MINSE markup using different
    compounds.  Function application is the only case implied just
    by the parentheses; the compound "openopen" is used for writing
    an interval open at both ends, alleviating this ambiguity.

14. The excerpt doesn't reach the end of the HTML ordered list <ol>.

15. Ron wrote:

> BTW, in using the convenient screen display form for <math> elements,
> I've segregated these elements so that the text of the paragraph after
> </math> starts on a new line.  I take it this adds significant space in an
> SGML document.

    I'm not sure i understand what is meant here -- adding any kind of
    extra whitespace to an HTML document doesn't change the spacing,
    except in PRE elements.  The layout is handled in the following
    markup using ordinary HTML elements, treating the SE elements as
    part of the text flow.  I used paragraphs because there is
    currently no means of setting out figures in HTML.  Upon seeing
    that figures would be a useful layout idiom for more than just
    images, i proposed something for it a while ago, but not much
    happened to it.  See

http://www.acl.lanl.gov/HTML_WG/html-wg-96q1.messages/0598.html

    for details.  The closest thing we have now might be MS Internet
    Explorer's "floating frame", but that is by no means standard.

    Excerpt from the above URL:

> This gives us an element for surrounding and positioning *anything*
> in a box with an optional caption, credit, or overlay. [...]


--------------------------------------- suggested HTML markup of example

<head>
...
<link rel=notation "http://.../somefile.not">
<link rel=context "http://.../somefile.ctx">
</head>

<body>
...

<p>The Euler equations for an inviscid incompressible 2-D fluid flow
are given by
<p align=center>
<se>'quot(D .oper ?nu?,D .oper t) = -'grad(p)</se>,
<se>x .eltof 'Real^2</se>, <se>t > 0</se>

<br>
<se>'diverg(?nu?) = 0</se>, <se>?nu?(x,0) = ?nu?;0(x)</se>
</p>

<p>where <se>?nu? = 'funcdep('pair(?nu?;1,?nu;2),t)</se> is the fluid
velocity, <se>p</se> is the scalar pressure,
<se>'quot(D .oper ?nu?,D .oper t) = 
    'partial(?nu?,t) + 'oper(?nu? .dot 'Grad, ?nu?)</se>,
and <se>?nu?;0</se> is an initial incompressible velocity field,
<i class=latin>i.e.</i> <se>'diverg(?nu?;0) = 0</se>.

<p>In this paper, we study the detailed limiting behaviour of
approximate solution sequences for 2-D Euler with vortex sheet
initial data.  A sequence of smooth velocity fields
<se>(?nu? .upidx ?epsilon?)(x,t)</se> is an <dfn>approximate solution
sequence</dfn> for 2-D Euler provided that the <se>?nu?</se> is
incompressible, <i class=latin>i.e.</i> <se>'diverg(?nu?) = 0</se>,
and satisfies the following properties:

<ol>
<li>The velocity fields <se>?nu? .upidx ?epsilon?</se> have uniformly
bounded local kinetic energy, <i class=latin>i.e.</i>

<p align=center>
<se>'max('integ('abs((?nu? .upidx ?epsilon?)(x,t))^2,x,'abs(x) <= R),
         0 <= i <= T) <= C</se>
</p>

<p>for any <se>R, T > 0</se>.

<li>The corresponding vorticity,
<se>?omega?^2 = 'curl(?nu? .upidx ?epsilon?)</se>,
is uniformly bounded in <se>L .upidx 1</se>, <i class=latin>i.e.</i>

<p align=center>
<se>'max('integ('abs((?omega? .upidx ?epsilon?)(x,t)),x),
         0 <= i <= T) <= C</se>
</p>

<p>for any <se>T > 0</se>.

<li>The vortex field <se>?nu? .upidx ?epsilon?</se> is weakly consistent
with 2-D Euler, i.e. for all smooth test functions,
<se>?phi? .eltof (C .upidx 'inf)('Real^2 .cartprod 'openopen(0,'inf))</se>
with <se>'diverg(?phi?) = 0</se>,

<p align=center>
<se>'lim('integ('integ(?phi?;t .dot ?nu?^2 +
         'matprod('Grad .oper ?phi?,
                  ?nu? .upidx ?epsilon? .tensorprod ?nu? .upidx ?epsilon?),
         x), t), ?epsilon? .approach 0) = 0</se>.
</p>

<p>Here <se>?nu? .tensorprod ?nu? = 'pair(v;i,v;j)</se>,
<se>'Grad .oper ?phi? = 'partial(?phi?;i,x;j)</se>,
and <se>'matprod(A,B)</se> denotes the matrix product
<se>'Sum(a;i;j,b;i;j,(i,j))</se>.  We remark in passing...

------------------------------------------------------------- discussion

On the whole, i think i'd have to say that the proliferation of
homonyms in Ron's example makes me rather uncomfortable.  Parens,
superscripts, and juxtaposition have so many different meanings
in the HTML markup he posted that -- even if it were possible for
mapping rules to choose which meaning is intended -- i don't think
i would just trust the rules to pick the right one every time, and
guessing exactly how to appease them by manipulating the notation
would quickly get troublesome.  I would much prefer getting into
the habit of consistently saying what i mean instead of hoping
that it gets interpreted right.

Moreover, what if authors later want to define new meanings for
juxtaposition or parentheses?  There seems to be no provision for
this because the juxtaposition itself is used to figure out the
meaning.  I think it makes more sense to go the other way, i.e.
from the meaning to the notation instead of guessing the meaning
from things like juxtaposition and parentheses.

I welcome your comments on this approach.  

I am sorry that i cannot participate in the conference calls,
but i imagine that this example will make a very interesting and
useful topic of discussion and i look forward to hearing about
what happens in your meeting.


Ping
Received on Sunday, 7 July 1996 22:19:08 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 15 April 2023 17:19:57 UTC