- From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- Date: Thu, 08 May 2003 16:42:21 +0200
- To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- CC: www-math@w3.org

Hi, I've finally had some time to some systematic proof reading. Here's a preliminary result. -- Andreas ========== 2.1.3, third paragraph, starts > A number of functions and operations require one or more quantifiers > to be well-defined. It should be 'qualifier', not 'quantifier'. 2.1.4, second paragraph > and should not require additional arguments or quantifiers to be fully > specified. Again, this should probably be 'qualifier', not 'quantifier'. 2.4.5, third paragraph. > The |id| is also used in this context. should read > The id attribute is also used in this context. 4.2.1, list of categories Move the last category listed (symbols and constants) to the first position in the list. Usually, lists like this are sorted from simplest to most complex concepts. 4.2.1.1, first paragraph > Numbers and symbols are marked by the /token/ elements |cn| and |ci|. add 'respectively'. > More elaborate constructs such as sets, vectors and matrices are also > marked using elements 'marked up' instead of 'marked'? 4.2.1.3 (whole paragraph) Mention the extra complication of qualifiers and declarations that change the basic pattern of <apply> op a b ... </apply>. This has become necessary since qualifiers are no longer tied to specific values of 'op' but available for use with user-defined operators, for example. 4.2.1.7 second paragraph > This is typically an |apply|, but can also be any container element. It may in principle also be an empty element denoting a constant. (This applies to 4.2.2.2 lambda as well) 4.2.1.7 Note that the lambda construct can be used with zero bvar elements to construct a 0-ary function (like random()). The way I read it, this paragraph allows this to happen (n=0), but implementers may miss this special case if it is not made explicit. (This applies to 4.2.2.2 lambda as well) 4.2.1.8 This currently mentions the use of qualifiers only with predefined MathML operators. It should also mention that it is possible to use qualifiers in any and all apply elements, including those that have csymbols or ci's or even compound first elements. The set example should mention that there are other similar cases where bvar qualifiers may be used (if there are any, that is -- matrix should be one such case, in my mind, as in A = matrix(a_ij) binding variables i and j). 4.2.2.2 matrix matrix and/or matrix-row should allow the use of bvars and condition or domainofapplication qualifiers to specify common notions like matrix A := (a_ij)_i=1..n,j=1..m: <matrix> <bvar> ... i ... </bvar> <domainofapplication> <interval> ...0... ...n... </interval> </domainofapplication> <matrixrow> <bvar>...j...</bvar> <condition> ...0<j<m+1... </condition> <apply> ...a... ...i... ...j... </apply> </matrixrow> </matrix> This applies to vectors, too. 4.2.2.3 mention again that declare is only allowed at the top-level. 4.2.3.1, third paragraph (arities list) There appear to be exceptions to this rule. - The spec contains an example where a missing argument is interpreted as a curried expression, that is the apply missing the argument is interpreted as standing for a function in that missing argument. - binary and n-ary functions often induce an easy generalization to variable-binding operators, e.g. plus -> sum, times -> product, and -> forall, or -> exists. In these cases, the operators would be called with a single argument only (despite being binary, for example), and with a bvar and a condition qualifier. 4.2.3.1, fourth paragraph "The one exception..." mention again that declare is only allowed at the top-level (I know that I used to mis-interpret this sentence to mean that a declare can be inserted at any level of nesting). 4.2.3.2 I notice that domainofapplication is listed as a qualifier here. Good. Make sure you mention that in 4.4.2.15. The second example uses <fn>. This is deprecated and should not be used in an example that does not serve as a counter-example. As mentioned earlier, I propose to deprecate the use of interval as a qualifier. This would cause several changes in this section. int; sum and product: > When used with |int|, each qualifier schema is expected to contain a > single child schema; otherwise an error is generated. This is only true if no interval qualifier schema is allowed (which I advocate). Intervals tend to have two children. diff: The example uses fn, which is deprecated. partialdiff: Why is the optional degree qualifier available for partialdiff but not diff? That seems inconsistent to me. forall, exists: I have argued elsewhere that it is not necessary to require at least one bvar qualifier to go with these. 4.2.4, third paragraph > It is an error to enclose a relation in an element other than |apply| > or |reln|. > Not true. Here is a counter-example that you'll find in my dissertation: <set> <lt/> <gt/> <eq/> <neq/> <leq/> <geq/> </set> I recommend removing this sentence, as I can easily imagine more cases like this with other containers. unary/binary/... : the discussion above applies here too. 4.2.5. mention that conditions can be used with arbitrary "heads" of their apply, just like bvars. 4.2.5.1, second example use MathML constant symbols instead of OpenMath csymbols for the sets N and P. 4.3.2.5 nargs: add a possible value to specify that the declared operator follows the model of quantifiers or sum/prod/int/max/min/... 'Binder' is used in OpenMath, 'quantifier' or 'generalized-quantifier' might be alternatives, too. 4.4.2.1.1 last paragraph Mention user-defined symbols in the context of qualifiers, too. 4.4.2.4.1, last sentence > The |interval| element expects /either/ two child elements that > evaluate to real numbers /or/ one child element that is a |condition| > defining the |interval|. > the condition qualifier has to be used with bvars according to earlier parts of the spec. Thus, we actually have 4 distinct possibilities: a) interval(a,b) b) interval(bvar(x),condition(p)) c) interval(lambda(bvar(x),p)) d) interval(p) where p is a unary predicate. However, I think that b) through d) are covered by the set and domainofapplication elements already, so that there is little to be gained from allowing them in addition to a). 4.4.2.7.1. mention that reln is deprecated. 4.4.2.9.1 it should be possible to use lambda to construct nullary functions (that is, use lambda with zero or more bvars). mention also the possible use of domainofapplication etc. 4.4.2.9.3 shouldn't the default rendering be more like \lambda x. f ? 4.4.2.11 shouldn't ident have an optional argument giving the domain it is the identity function for? Default rendering of ident(D) would then be id_D. 4.4.2.15 mention that domainofapplication is a qualifier element. 4.4.2.16 I'm not sure that it is a good idea to disallow degenerate versions of piecewise that have no piece elements at all. When this kind of expression is generated by computer, I can easily imagine cases where somewhere in the simplification chain for a smooth function description it might go through just such a form, to be simplified in the next step. However, one could imagine a case where the knowledge for this extra simplification step that strips away a piecewise with a single otherwise child resides in an external application... Even the completely degenerate form of an empty piecewise expression could easily come up in a chain of reasoning that proves that a certain function definition leads to an empty domain. 4.4.3.5 add a unary minus example. 4.4.3.17, 4.4.3.18 again, I have argued elsewhere that requiring a bvar is unnecessary as there are common examples where one does not appear. 4.4.5.1.1 The domain of integration may actually be specified in more different ways: lowlimit/uplimit, interval (which should be deprecated), domainofapplication, condition (with bvar(s)). Mention that the bvar element specifies the integration variable. 4.4.5.1.2 If the use of interval as a qualifier is deprecated (as it should), the second example needs to be changed so that the interval element is wrapped with a domainofapplication. 4.4.5.2.2 add a degree example. I'm surprised that diff is only for single-variable differentiation. I thought that it would also stand for total differentiation in multiple variables. In this case, optional degree arguments and the possible two-argument variant specified in partialdiff should apply here, too. 4.4.5.6.1 mention that bvar can be used with user-defined or even compound "heads". 4.4.5.6.3 the default rendering of the first example should be $\frac{d^2 x^4}{dx^2}$ 4.4.5.8/9/10 add default renderings with \nabla, as in the case of the laplacian. 4.4.6.9/10 the default renderings in 4.4.6.9 and .10 need to be swapped. 4.4.6.13 we're clearly missing a cartesianpower element to represent $\R^n$, n-dimensional real vector space -- although cartesianproduct(bvar(i),condition(0<i<n),reals) would work, too ;-) 4.4.7.1, .2 we can also use domainofapplication here. Mention also that a function argument without a bvar qualifier is possible. Appendix I.2, last sentence. There is a grammatical error in this sentence.

Received on Thursday, 8 May 2003 10:42:26 UTC