- From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- Date: Fri, 09 May 2003 16:58:38 +0200
- To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
- CC: www-math@w3.org

Hi, here is another set of comments on roughly the first half of Appendix C. Can I have an extension of the deadline for comments? I'd like to finish this chapter and appendix B next week. Sorry -- I had more comments to make than I had thought beforehand. Anyway, I hope this helps, -- Andreas ============================================ C.1 second paragraph, second sentence strike 'if' C.1.1 first paragraph, first sentence 'used' -> 'use' C.1.1 third paragraph first word "This" -> 'The'; insert comma after 'standardization effort' C.1.2 - function (operator), second paragraph, third sentence insert 'as' after 'used' - signature, second paragraph, first sentence 'to type of mathematical object that is constructed.' -> 'to the type of the mathematical object it constructs' (for example) C.2.2.2 replace 'reln' by 'apply' in the formal production rule. Rationale: the application should have used 'apply' instead of 'reln' anyway, so just treat it as one semantically. C.2.2.3 "This constructor has been deprecated": I've been confused, reading the spec, to what extent this is true. Sometimes the spec seems to say that fn has only been deprecated for certain uses rather than fully and completely. Please check all places in the spec that have fn in them to check what exactly they say about deprecation, and make sure they all agree. C.2.2.4 There is a consistency problem here. a) This chapter has interval as a constructor only, not as a qualifier. Since I recommend removing the use of interval as a qualifier, this is fine with me, but consistency with the rest of the spec is important here. b) Chapter 4 describes how to use interval with a single argument, a condition. Note that I commented on that earlier, with a recommendation to strike that extra complication, in which case this paragraph would be correct. As Chapter 4 stands, however, the single-argument condition version of an interval is undefined here (if it is kept). C.2.1.2 vs. C.2.2.5 the first example uses <ci type=function>, but 'function' is not an allowable type listed in C2.1.2 nor could it be deduced from rules that include constructor element names by reference into the list of allowed types for ci (type =lambda might work ;-) . This is a problem of consistency only. I recommend adding function in C.2.1.2 in order to resolve this issue. C.2.2.7 signature '(apply)' is too restrictive, since constants and symbols should be allowed. Also, somewhere in the spec it says you can use sets as conditions, not just predicates. In that case, set name symbols would be useful in more than just degenerate cases. C.2.2.9 the formal signature and the rest of this paragraph (correctly!) state that there are zero(!) or more occurrences of bvars. Other places in the spec (incorrectly!) insist on at least one bvar, including the content markup validation grammar. There is an inconsistency here. > Note that a lambda expression on an arbitrary function applied to a > simple argument is equivalent to that arbitrary function. > I don't understand the previous sentence. If you mean to express \lambda x. f(x) = f then the sentence needs to be re-phrased in order to ensure that the 'simple argument' is the single bound variable of the lambda, because the statement is false otherwise. C.2.2.10 use a small circle Unicode character instead of @ in the description. C.2.2.13 The property should use Exists as in Forall(y, Exists(x,y=f(x)), y in codomain(x)) C.2.2.14 The property should involve image, not codomain. Also, you have a definitory equivalence and not just an implication here, which you may want to express. How about this extra example: Forall(f, x in image(f), x in codomain(f)). C.2.2.15 this should mention that domainofapplication is a qualifier element. The formal signature is incorrect, as the example shows. Its argument is a set, not a function, and its result is the same set (it it can properly be seen to have a result, since it really is a qualifier changing the meaning of the surrounding apply). I don't think this belongs into this section. I think it should go wherever condition is defined. C.2.2.16 The formal signature allows zero pieces, but requires at least one otherwise. The former is correct, the latter incorrect (it should be zero or one otherwise). Note also that there are consistency issues with respect to Chapter 4 and with suggestions I have made on that chapter. C.2.2.17 The formal signature is incorrect. Replace 'algebraic' by 'anything'. Rationale: you can define a piecewise relation, too, though admittedly that would be a bit unusual. C.2.3.1 first paragraph 'positive' -> 'non-negative' (since a may be 0) C.2.3.4, C.2.3.5 I'm not sure if the 'condition' in the formal signature includes domainofapplication elements. If not, this needs to be amended. Also, to be consistent with, say, int, the signature (domainofapplication, function) -> anything [or perhaps (... -> codomain(function)), to be more specific] should be allowed with the meaning of the supremum of the function over the specified set. In the last example, the interval should render as a closed interval. C.2.3.12 add signature (anything*) -> anything. Rationale: there are lots of other places where a gcd makes sense, and not all of them have a well-defined MathML-type to go with them. add signature (bvar,condition,anything) -> anything which defines the gcd of all elements thus described. [This extra signature should be added to all nary function symbols (plus, geq, and, etc.) in MathML because the spec allows it and it makes sense.] May also need to add signature (domainofapplication,function) -> anything [again for all other nary function symbols, too]. C.2.3.18 If you specify earlier, as I recommend here, that the type of a reln is apply, then you can strike the second signature. If you go with an earlier recommendation of mine, you should allow the signature (domainofapplication,function) -> boolean. Note that this specification (correctly!) says that there are zero(!) or more bvars. I have noted previously that there are cases in other parts of the spec that claim that there needs to be at least one bvar. C.2.3.19 The description and the signature are incorrect, and should be rewritten from scratch based on the (corrected) text for forall (C.2.3.18). C.2.3.23 For clarity, make the MathML type=real explicit in the ci elements of the MathML version of the property. (actually, the default type of a ci element is specified as complex somewhere, isn't it? in that case, this change is necessary to make the property come out right.) C.2.3.24 The property is only correct if the type of x and y is specified as real. See C.2.3.23. C.2.4.2 An n-ary version of neq makes sense too, returning true if none of the arguments are equal. this paragraph should be more like the ones for eq, lt, gt, leq, and geq then. C.2.4.7 Why does this use logical instead of boolean??? Also, why can't equivalence be used to represent arbitrary equivalence relations over arbitrary domains (with signature (anything*)->boolean)? C.2.5.1 Add signature (domainofapplication, function) -> anything which is needed in some examples in this spec (e.g. $\int_D f$). I also suggest removing the interval signature, based on previous comments I have made. It may also be necessary to add (bvar, domainofapplication, algebraic)->algebraic if domainofapplication is not included in condition. In addition, the spec says in other places that more than one bvar is allowed in most cases, and this should be reflected in the signatures. C.2.5.2 I remarked in my previous posting that this should perhaps be defined more like partialdiff. C.2.5.3 The examples and properties should use partialdiff, not diff. The third property is not allowed by the signatures. Either fix the property or the signatures.

Received on Friday, 9 May 2003 10:58:43 UTC