W3C home > Mailing lists > Public > www-math@w3.org > September 2003

Comments on changes in MathML PER 2.0, Chapter 4

From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
Date: Wed, 10 Sep 2003 13:04:03 +0200
Message-ID: <3F5F0523.6030704@rrz.uni-koeln.de>
To: "www-math@w3.org" <www-math@w3.org>


here are my comments on the extensive changes proposed for Chapter 4, 
which largely appear to address issues that I had raised during the 
final-call period.  Since the changes were quite extensive, I have many 
comments, mostly editorial.

However, one major point that I have been raising for a long time now, 
namely the ambiguity between uses of interval as a constructor or as a 
qualifier, was supposed to have been addressed in this edition in a way 
that I had approved on this list, but I cannot find the text that had 
been posted here anywhere in the changes to chapter 4.  This problem is 
therefore still open.

-- Andreas


        > The lambda construct

>"This is followed by an optional |domainofapplication| qualifier"

For reasons of consistency, I would like this to refer to text that declares all the 
different ways that a domain of application can be specified in MathML 
according to the clarifications made in this update.  An easy way 
editorially to clarify the meaning of the above phrase is to link from 
the word domainofapplication to the place where the semantic equivalence 
of the several ways of specifying domains of application are described, 
e.g. (quoting  another place in the spec):
"Qualifications defined by a |domainofapplication| element can be 
abbreviated in several ways as described in Section 4.2.3 Functions, 
Operators and Qualifiers <#contm.funopqual>."

        > The use of qualifier elements

Somewhere in this section, the resolution to the interval ambiguity
that you posted on this list earlier should be included.  As it is,
the ambiguity is not really addressed properly yet anywhere in this

>"by restricting the values of the |bvar| element"

This is a bit tricky.  At first, I thought that this should read bvar 
"qualifier" instead of "element," but in fact, neither really fits. Neither 
bvar elements nor qualifiers have "values", really.  What is actually 
restricted here is the range of possible values of the (mathematical) 
variable which is specified through the use of a bvar qualifier.

> "...|condition| element can be used to place restrictions directly 
on the on a bound variable..."

Typo ("on the on a").

>"This general construction gives natural lifted version of many n-ary 

There is a minor grammatical error in this sentence; it should read 
either "a natural lifted version" or "natural lifted versions".

>"many n-ary operators, such as..."

Is this list meant to be exhaustive with respect to the predefined 
MathML operators? If yes, compose and the n-ary relations equal etc. are missing.

You may also want to produce a similar list (lambda, set, list, vector, matrix...)
of constructors that take these qualifiers, after the set example.

>"The meaning of constructions of the second form is that the function in 
the last child is applied to all the values of the set in the 
|domainofapplication| qualifier."

This is not actually correct, since it misses the fact that the n-ary 
operator needs to be applied, too, in order to get the correct meaning. 

How about something like this:
"The meaning of expressions of the second form is that the operator is 
applied to the all the values obtained by applying the function in the 
last child to the elements of the domain of application specified in the 

        > Constructors

For the updated portions of text describing the use of these 
constructors (set, list, matrix...) with bvars and domains of 
application, it would be nice to have examples of these newly clarified 
uses for implementors to test their products on.


The subsection on the lambda constructor is no longer correct since it 
misses the possible use of domainofapplication or its abbreviations 
described earlier in the spec. A possible solution here is to describe 
the use of lambda more vaguely rather than more precisely, so that 
dom-of-apps would be allowed by the vaguer description without being 
mentioned explicitly.

        > Predefined functions and operators

>"The number of child elements in the |apply| is defined by the element 
in the first (i.e. operator) position..."

This has been softened for the n-ary operators, but I thought I had 
pointed out that it also needs to be softened with respect to the effect 
of currying, which essentially allows one to drop arguments from the 
right, producing implicit functions in the dropped argument. E.g. binary 
functions can have a single argument, in which case they denote a unary 
function in the dropped (second) argument.  (This was one of the points 
of my question whether or not MathML really wants to define currying or 
not, which has been adressed elsewhere in the text but not here.)

((After re-reading this, and going through the entire chapter 4, it now
seems to me that MathML no longer supports currying at all, as the one 
place where this feature appeared has been deprecated.  If this is correct,
the above comment becomes moot, of course.  Removing support for currying
is probably not a bad idea, given the problems I found in OpenMath in that

        > Operators taking Qualifiers

I noticed that you changed the list of operators taking qualifiers, but 
I don't understand why this list does not include all those mentioned in 
the (slightly incomplete) one in mentioned above. (Also, add 
commas between the newly added elements).

>"...except that when they are used as operators, certain qualifier 
elements are also permitted to be in the enclosing |apply|"

This is confusing, since qualifier elements are always "permitted" 
according to other parts of the spec (which makes sense since predefined 
elements may be assigned a different semantics via a definitionURL 
declaration or a semantics element).  

>"The most general qualifier is the |domainofapplication|. "

Slightly confusing -- it's really only the most general of those 
qualifiers that denote restrictions on the domain of application of the 
surrounding constructor (condition, interval, lowlimit...), but not the 
most general qualifier of all (which would include bvar and others...).

>"danger of confusing the role one of the short forms"

... role *of* one of...

>"Note that the order of bound variables of the integral must 
correspond to that used by the |set| constructor in the 

I don't think that that is correct, nor necessary.  Their order has to correspond 
to the order of the entries in the list constructor within that set, not
the order in which the bvar elements appear in the embedded set. The 
following example (which identifies arguments only by their order within a 
cartesian product) should also be allowed as the body of the 
domainofapplication qualifier in the example the above text refers to:
This corresponds to a venerable tradition of mathematical notation.

>"By using the deprecated |fn| element, it was possible to associate a 
qualifier schema with a function..."

This seems to imply that currying is now deprecated along with the fn 
element. Is that really intended?  As I pointed out earlier, I would 
have expected you to amend this example to the following otherwise 
(simply dropping the fn):


Note that I'm not criticizing -- I realize very much that introducing 
currying semantics into MathML is dangerous, given the problems I 
discovered in a related area in OpenMath. I'd just like to make certain
that deprecation of currying was the intended result here.

>"The meaning and usage of qualifier schemata varies from function to 

You may want to qualify this strong statement a bit by pointing out that 
the bvar and domain-of-application type of qualifiers are used with a 
consistent semantics across the MathML operators and constructors, and 
are meant to be used just as consistently with user-defined symbols 
or with any other constructs.  (That way, OpenMath would be justified in 
mapping bvar to an OMBinding element across the board, for example).  I 
think you simply missed this implication of my previous comments on 
generalizing the use of these qualifiers.

>forall, exists

You missed generalizing the condition to a general domain-of-application 
here. This also misses the fairly common use of a quantifier with a 
functional argument --  (\forall \lambda x. P(x))  and  (\forall_R 
\lambda x. x<1)  are examples. Both of these I mentioned in previous 

>4.2.4 Relations

>"The number of child elements in the |apply| is defined by the element 
in the first (i.e. relation) position."

This should refer back to, or repeat, the discussion of arity and its 
complications for functions.  (My earlier comments had pointed out that 
they referred to both.)

        > Examples

The first example doesn't have an argument. In other places in the spec, 
this was interpreted as currying, which would not give the 
interpretation that is specified in the accompanying text.  I suggest 
deprecating this example.  (I made a similar comment about another 
currying example of the MathML spec earlier.)  I would also suggest 
using domainofapplication instead of condition somewhere in these 
examples (e.g. where it says "\in \C").

> Examples / Default Rendering

The type=constant example (tau) and its rendering (pi) don't match.

> Examples / Default Rendering

The final example (x_a) and its rendering (x_i) don't match.

          > Discussion

>"then it is treated as if it were the content of an |fn| element."

Rephrase as in where another problem like this was fixed.

>"Some operators such as user defined functions defined using the 
|declare| or |csymbol| elements, |diff| and |int| make use of "named" 

I discussed this one at length.  It still lacks mention of those "other 
constructs" mentioned earlier in the spec which allow those "named 
arguments"; in fact, it should say that qualifiers are allowed in an apply 
regardless of its first child.  I believe I gave examples of quantifiers 
constructed using a lambda expression to show that the range of 
allowable operators that go with qualifiers extends beyond symbols.

          > Discussion

>"When used in the body of an |apply| element it serves as a shorthand 
notation for a |domainofapplication|."

This would mean that the example
would not denote addition of intervals (as I believe we agreed it 
should).  I therefore suggest qualifying this sentence with "sometimes" 
or "may", and referring to the part of the spec that explicitly resolves 
the interval ambiguity.

((Come to think of it, I didn't see this ambiguity resolved yet in the 
way that you posted on this list. The section on operators taking qualifiers
doesn't address the ambiguity at all. This problem is therefore still open!!))

          > Default Rendering

The first default rendering is incorrect, as the example does not 
specifically name the set of real numbers.

          > Discussion

This doesn't mention that the declare element is only allowed at the top 
level.  This problem has been fixed in other places of the spec, but 
this one was apparently missed.

>"implied by the use of the |semantics| element. without having to write"
Spurious period in the middle of the sentence.

>"XML space normalization"
Please provide a normative reference for this concept.  I can't find any 

          > Discussion

>"The bound variables can be restricted by an optional 
|domainofapplication| qualifier."
I thought  the abbreviations would also be allowed here.

>"If a |lambda| construct does not contain bound variables, then the 
arity of the constructed function is unchanged, and the |lambda| 
construct is redundant, unless it also contains a |domainofapplication| 

Actually, you do need a lambda with no bvar and no domainofapplication to 
define nullary functions like random(), as I pointed out in my original 
request to allow lambda with zero bvars.  Thus, the interpretation of 
lambda with no bvars as applying to an argument function should *only* 
be used when a domainofapplication is present.  This distinction would 
be more consistent, I believe, and it works better within the framework 
that I had discussed in my original posts on this topic, too.

          > Default Rendering

Is there really supposed to be a closing parenthesis in the default 
rendering of "sine restricted to I"? 

          > Discussion

>"As n-ary operators, these operands may also be generated by allowing a 
function or expression to vary over a domain of application"
... its operands... (as in the gcd section; you just missed this one)

 And (and) Or (|or|) Exclusive Or

These are all n-ary operators. Their explanations should include phrases 
like the one in the previous comment, either along the lines of the one 
for gcd, say, or along the lines for plus (e.g. pointing out that the 
lifted version of "or" is "exists"). Universal quantifier (|forall|)

> "It must be used in conjunction with one or more bound variables"
To be consistent with lambda, sum, int, this should allow the functional 
interpretation in case of zero bound variables, as I have pointed out 

>"an optional |condition| element"
This should have been generalized to the domainofapplication.

        > Existential quantifier (|exists|)

You forgot to fix "exists" along the same line as "forall".

        > Equals (|eq|), Greater than (|gt|),
       Less Than (|lt|), Greater Than or Equal (|geq|),
       Less Than or Equal (|leq)|, Equivalent (|equivalent|)

          >"The |...| element is an /n-ary relation"/

...and therefore may be used with qualifiers.  (You missed these cases, 
which should be treated along the lines of gcd).

          > Examples

>"An indefinite integral is represented by applying the |int| operator to 
a function without bound variables and qualifies as in..."

This sounds like the functional form is now the *only* way to represent 
indefinite integration. I don't think that that was intended, and 
therefore recommend continuing the above sentence with " ... or by using 
the int operator with a bvar qualifier indicating the integration 
variable...", adding a second example illustrating this case.

You may also want to include an example of definite integration in the 
functional form as an added illustration that the distinction between 
the functional form of int and its form using bvar is independent of the 
distinction between definite and indefinite integration; e.g.
      <ci type="set">D</ci>
    <ci type="function">f</ci>

        > Bound variable (|bvar|)

I'm missing mention of the fact that bvar can even be used when the 
first child of an apply is a compound expression.

>"...XML space normalization."

Again, please link to a normative reference for this term. I couldn't 
find one.

>"It can be necessary to associate additional information with a bound 
variable or one or more instances of it..."

Mention also that an associated domainofapplication or one of its 
abbreviations can serve to add certain kinds of information to a bvar.

        > Cartesian product (|cartesianproduct|)

>"The |cartesianproduct| element is a /n-ary set operator..."
... and can therefore take qualifiers... Sum (|sum|)

>"The most general form of a sum specifies the terms of the sum by using 
a |domainofapplication| element."

Not true: the terms of the sum are specified by the argument element of 
the sum, not the domain of application (otherwise, a sum would almost 
always return an integer.)  I suggest rephrasing this. Product (|product|)

The way this is described, replacing sum by product in the final example 
for sum would not be allowed. Perhaps one should just apply the same 
changes as were made for sum in this paragraph, too, or refer back to 
sum and state that product works just like sum etc. Mean (|mea|n), Standard Deviation (|sdev|)...

|>"mean|,sdev,variance,median,mode, is an /n-ary operator"

... and therefore can take certain qualifiers...

(also, this paragraph accidentally slipped down into the examples section) Vector (|vector|), Matrix (|matrix|)

I believe you stated that you wanted to allow vectors and matrices to be 
constructed with bvars and domains of applications, like lists and sets. 
This is missing here.
Received on Wednesday, 10 September 2003 07:05:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:34 UTC