on goals (repost)

The bracketed numbers are references to messages by number on the
mailing-list archive; the other bracketed references are given at
the end of this message.

--------------------------------------- two-dimensional representation
[009] T. V. Raman writes:
> Renderings in speech need to convey more than a "2D picture" of the
> expression.

I definitely agree with what Raman says here.

That document at [GENERAL] makes many references to a "2-D
presentational structure" and a "2-dimensional form of an expression".
I believe this is *not* what a mathematical or structured-expression
notation should be based upon, and i disagree with this statement as
as a design goal [DESIGN].

A two-dimensional model is too limiting and presentation-specific.
The goal should be a language that conveys the semantics and structure
of an expression.

[012] Dave Raggett writes:
> Raman voiced a concern on Bruce's comment on 2D pictures. We agreed
> however, that a fixed set of "layout" idioms are sufficient for
> HTML-math.

A fixed set of "layout" idioms for printing and 2-D screen display are
fine.  We should be able to easily define other rendering idioms for
other media, though.  MINSE calls these idioms "primitives" (because
rendering structures are built from them); while there are things like
@bar, @sup, and @big among the video primitives [GLYPHD], possible
audio primitives include @pan, @inflect, or @speed.  I'm curious to
know if ASTeR uses an intermediate output format like this.

-------------------------------------------------- capturing semantics
[038] Ron Whitney writes:
> A full definition isn't
> required, but we all anticipate that html-math will feed into various
> processors which manipulate the html data in mathematical ways, and
> I'd like a somewhat clearer notion of how others here understand the
> "semantics" we're trying to capture.

Ideally we should be able to get enough meaning into most expressions
to be able to "render them out" to something which can be directly
manipulated by Maple or Mathematica, in addition to being represented
as images, audio, or say TeX.

> A more complicated case lies in the various uses of, say, ^ as a
> "power" operation.
[...]
> The distinguishing
> force is that these "really are" (say in a computational or other
> formal sense) different uses of the term (e.g. one wants to say the
> exponential function *truly* isn't a power at all) and should be
> distinguished as such.

I perceive the exponentiation of numbers and the composition of
functions as two different operations, and so while they are
sometimes written similarly, MINSE has different compounds for both
('exp and 'composen, respectively).  Different operations are
always given different compounds, even if they may render the same
way.  This is crucial to preserving the meaning of the expression. 

-------------------------------------- the importance of extensibility
[070] Neil Soiffer writes:
> I heard from Steve Hunt (at the paris HTML meeting) that Dave Ragget
> felt it was worth pursuing a two phase approach, with the first phase
> being the basic syntax as Bruce and I have proposed
[...]
> Phase two of the standards is the more iffy part: adding macros/mapping
> rules/pattern matching or whatever to allow for extensions of the base
> standard and easier authoring and conversion to other systems.  I imagine
> this would be another year in the making.

I am wary of this approach.  My past experience (little as it has been,
probably, compared with most of you -- but anyway) has been that unless
a system is designed with extensibility at the start, it can get messy
to try to extend things later on.  I have kept this in mind in the design
of MINSE by allowing the redefinition of notations [NOTATION] and styles
[STYLE] right at the outset.  MINSE is already fully extensible.

-------------------------------------------- about being math-specific
[089] Bruce Smith writes:
>       The solutions to the general quadratic equation:
>       <math mode=inline>
>       ax^2+bx+c=0
>       </math>

A number of times on this mailing list now i've seen mention of
this new <math> tag.  I have some reservations about creating a
tag called MATH (and, indeed, about naming the entire proposal
"HTML-Math"), because it is my hope that such a system should not
limit itself to just mathematics.  I tried to avoid using the
word "math" in MINSE's name, for instance (though the pathname
on the site is still "/math/").

MINSE was designed to be extensible at the outset, and can support
multiple notations and multiple contexts (as soon as i define
some more).  This is why i think a name like <se> ("structured
expression") is a better choice.

Notation definitions are separated from style definitions,
because the former come before the semantics and the latter
come after.  Thus the former are chosen by the author, and
the latter are selected depending on the target media (perhaps
with hints from the author and reader).

----------------------------------------------------------- references

[009] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00009.html
[012] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00012.html
[038] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00038.html
[070] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00070.html
[089] http://lists.w3.org/Archives/Public/w3c-math-erb/msg00089.html

[GENERAL]  http://www.w3.org/pub/WWW/MarkUp/Math/WG/Wolfram/general.html
[DESIGN]   http://www.lfw.org/math/design.html
[GLYPHD]   http://www.lfw.org/math/styles.html#implementation
[NOTATION] http://www.lfw.org/math/notations.html
[STYLE]    http://www.lfw.org/math/styles.html


Thanks for reading.


Ping