- From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- Date: Wed, 10 Sep 2003 13:04:03 +0200
- To: "www-math@w3.org" <www-math@w3.org>
Hi,
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
=======================================================================
>4.2.1.7 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>."
> 4.2.1.8 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
chapter.
>"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
operators"
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
qualifiers."
>4.2.2.2 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.
>lambda
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.
> 4.2.3.1 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
area.))
>4.2.3.2 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 4.2.1.8 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
|domainofapplication|."
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:
<apply>
<cartesianproduct/>
<interval><ci>0</ci><ci>1</ci></interval>
<interval><ci>0</ci><ci>1</ci></interval>
</apply>
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):
<apply>
<int/>
<interval><cn>0</cn><cn>1</cn></interval>
</apply>
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
function."
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
discussions.
>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.)
>4.2.5.1 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").
> 4.4.1.1.3 Examples / 4.4.1.1.4 Default Rendering
The type=constant example (tau) and its rendering (pi) don't match.
> 4.4.1.2.3 Examples / 4.4.1.2.4 Default Rendering
The final example (x_a) and its rendering (x_i) don't match.
>4.4.2.1.1 Discussion
>"then it is treated as if it were the content of an |fn| element."
Rephrase as in 4.4.2.8.1 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"
arguments."
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.
>4.4.2.4.1 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
<apply>
<plus/>
<interval>...</interval>
<interval>...</interval>
</apply>
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!!))
>4.4.2.7.3 Default Rendering
The first default rendering is incorrect, as the example does not
specifically name the set of real numbers.
>4.4.2.8.1 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
definition.
>4.4.2.9.1 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|
construct"
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.
>4.4.2.9.3 Default Rendering
Is there really supposed to be a closing parenthesis in the default
rendering of "sine restricted to I"?
>4.4.3.4.1 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)
4.4.3.12 And (and) 4.4.3.13 Or (|or|) 4.4.3.14 Exclusive Or
(|xor|)
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").
4.4.3.17 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
before.
>"an optional |condition| element"
This should have been generalized to the domainofapplication.
>4.4.3.18 Existential quantifier (|exists|)
You forgot to fix "exists" along the same line as "forall".
>4.4.4.1 Equals (|eq|), 4.4.4.3 Greater than (|gt|), 4.4.4.4
Less Than (|lt|), 4.4.4.5 Greater Than or Equal (|geq|), 4.4.4.6
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).
>4.4.5.1.2 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.
<apply>
<int/>
<domainofapplication>
<ci type="set">D</ci>
</domainofapplication>
<ci type="function">f</ci>
</apply>
>4.4.5.6 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.
>4.4.6.13 Cartesian product (|cartesianproduct|)
>"The |cartesianproduct| element is a /n-ary set operator..."
... and can therefore take qualifiers...
4.4.7.1 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.
4.4.7.2 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.
4.4.9.1 Mean (|mea|n), 4.4.9.2 Standard Deviation (|sdev|)...
(variance,median,mode)
|>"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)
4.4.10.1 Vector (|vector|), 4.4.10.2 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