From: Andreas Strotmann <strotman@nu.cs.fsu.edu>

Date: Thu, 30 Mar 2000 13:58:34 -0500 (EST)

To: David Carlisle <davidc@nag.co.uk>

cc: www-math@w3.org

Message-ID: <Pine.GSO.4.10.10003301314220.6438-100000@xi.cs.fsu.edu>

Date: Thu, 30 Mar 2000 13:58:34 -0500 (EST)

To: David Carlisle <davidc@nag.co.uk>

cc: www-math@w3.org

Message-ID: <Pine.GSO.4.10.10003301314220.6438-100000@xi.cs.fsu.edu>

Hi, here's a re-submission of a long message I sent to this list in January, with issues that have been addressed in the current draft removed from the message, and the comments shortened somewhat (since everybody can refer back to the original post in January). I've also added a couple clarifications. Some of these issues I believe to be very important, in particular my proposal (in synch with OpenMath) to allow the bvar (and condition) qualifiers to appear in any <apply>, with a default semantics which is already specified in the Working Draft, plus the proposal to have the names of basic sets (empty set, N, Z, Q, R, C) part of MathML. Since this is a final draft, I really recommend that these problems be addressed before a final MathML 2.0. I would be glad to help work out concrete phrasing and tracking of consequences of proposed improvements through the document. Best regards, Andreas Strotmann ================================================================ > 4.2.3.2 int:, it is not an error if the interval schema has two > children; hence rephrase the final sentence. > > -- 4.4.2.1 csymbols and fns can denote operators: are such operators > allowed to take "named" arguments, too, such as <bvars> and <conditions>? > > "Some operators such as diff and int make use of `named' arguments. These > special arguments are elements that > appear as children of the apply element and identify `parameters' such as the variable of differentiation or the > domain of integration. These elements are discussed further in section ??? > Operators taking qualifiers" > > I think I argued earlier that it would be a very good idea to allow at > least the bvars (with the general notion of variables bound by the > operator). With the general meaning of conditions as representing a type > for the bvars, I'd also prefer to have these available for user-defined > operators or other operators or quantifiers not available in MathML. Examples: 1) quantifiers such as "exists uniquely" (rendered as an "exists" with a dot above) and "almost every" (rendered as a "for all" with a dot above) I have personally encountered in undergrad calculus and linear algebra courses, or in functional analysis, resp. [the latter means "the assertion is true except on a subset with measure zero", if I recall correctly). 2) operators such as "the intersection of the family of sets A_i indexed by variable i ranging over the odd integers" -- constructed similarly to the product and sum operators -- are ubiquitous in math, as they generalize immediately from any binary associative operator to an operator that requires a variable. Allowing <bvar> elements in any <apply> would also increase compatibility with OpenMath, where this capability is achieved using a BIND element. Currently, MathML does not directly support the introduction of quantifiers or operators that are consistently used in the same way that their analogues in MathML ("forall" or "sum") are used. That is a bad design choice. Note also that any MathML application that already handles "exists" and handles "sum" would easily be extended to handle a generalized version of "apply" that always allows bvar and condition qualifiers, regardless of the concrete operator applied. > -- 4.4.2.7 Shouldn't we have the basic sets in MathML (N,Z,Q,R,C)??? > As it stands, the default rendering for examples as given in the > recommendation is incorrect since nothing allows the renderer to infer > that R stands for the reals. > > > -- 4.4.2.9 should lambda allow <condition> to specify the ranges of > bound variables? (cf. my comment on 4.4.2.7 above) > > -- 4.4.2.11 the identity function is often annotated by its domain as a > subscript. <condition>? > > -- 4.4.6.1 It's useful to mix condition elements and arguments in sets, > as in {x\in N | x < 5} where x\in N is best seen as a <condition> and > x<5 best seen as an <apply> argument. (The same is true for lists, 4.4.6.2.) > > > -- 4.4.10 Why is there no <bvar> vector or matrix constructor like a set > or a list constructor? Example use: (for i=0..n-1,j=0..m-1, A_i= x_i^j) > > > -- Appendix C still uses lots of <reln>s, e.g.: > > "<property> <reln><identity/> > <cn>ⅈ </cn> > <apply><root><cn>-1</cn><cn>2</cn></apply> > </reln> > </property>" > > > -- literature references: > > you may be interested in our papers, > > Ladislav J. Kohout, Andreas Strotmann: "Understanding and Improving > Content Markup for the Web: from the Perspectives of Formal Linguistics, > Algebraic Logics, and Cognitive Science." in ISIC/CIRA/ISAS 98 Joint > Conference on the Science and Technology of Intelligent Systems, > Gaithersburg, MD, 1998. [[This was also presented at the Tallahassee OpenMath workshop, and I'd like to present something like it at the MathML workshop.]] > > John A. Abbott, Andre van Leeuwen, Andreas Strotmann: "OpenMath: > Communicating Mathematical Information between Co-operating Agents in a > Knowledge Network". Journal of Intelligent Systems no. 3/4, 1998. [aka the > "OpenMath Objectives" paper.] >Received on Thursday, 30 March 2000 13:58:51 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Saturday, 20 February 2010 06:12:49 GMT
*