- From: Stan Devitt <jsdevitt@stratumtek.com>
- Date: Thu, 10 Jul 2003 10:09:40 -0400
- To: www-math@w3.org
Andreas,
Continuing with the resolutions:
Again we have worked through all the straight editorial pointers below
and will not dwell on them here.
Also, a number of the points you have below relate to signatures that
are missing, off by 1, or generally
too restrictive.. There has been a full review of the signatures to
make them more consistent with
the possible arities. In most, but not all, cases we have have changed
it as you suggested. We have
tried to keep the signatures "informative" so that the types you would
usually expect to be found
in certain positions are visible. One significant consequence of your
questions has been that the
introduction now discusses a "domainofapp" which stands for
"domainofapplication" or any
of its abbreviations and this is used throughout in the signatures
with (domainofapp,function) -> algebraic
occurring in quite a few places that it had been missed.
With this in mind, the main issues that you raise and their disposition
are shown below.
As usual, a response acknowledging these outcomes would be most helpful.
Stan Devitt
Math Working Group.
>
> errata and comments, chapter C (first installment)
>
> *From:* Andreas Strotmann (/Strotmann@rrz.uni-koeln.de/
> <mailto:Strotmann@rrz.uni-koeln.de?Subject=Re:%20errata%20and%20comments,%20chapter%20C%20%28first%20installment%29&In-Reply-To=<3EBBC21E.9080803@rrz.uni-koeln.de>&References=<3EBBC21E.9080803@rrz.uni-koeln.de>>)
> *Date:* Fri, May 09 2003
>
> ------------------------------------------------------------------------
> <mailto:www-math@w3.org?Subject=Re:%20errata%20and%20comments,%20chapter%20C%20%28first%20installment%29&In-Reply-To=<3EBBC21E.9080803@rrz.uni-koeln.de>&References=<3EBBC21E.9080803@rrz.uni-koeln.de>>Subject:
> errata and comments, chapter C (first installment)
>
>Hi,
>
>here is another set of comments on roughly the first half of Appendix C.
>
>
>
[JSD]... several routine editorial items
>
>C.2.2.2
>
>replace 'reln' by 'apply' in the formal production rule. ...
>
[JSD] fixed.
>
>C.2.2.3
>
>"This constructor has been deprecated": ... Sometimes the spec seems to say that
>fn has only been deprecated for certain uses rather than fully and
>completely. ...
>
[JSD] The wording here and in chapter 4 has been reviewed to make clear
that all uses of the "fn" constructor are deprecated.
>
>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.
>
[JSD] Again, this is the issue of the dual role of the interval. The
resolution of
this has been described elsewhere; it is retained, and rules are
provide to
resolve any ambiguities.
>
>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).
>
[JSD] The description in chapter 4 was a hold-over from version 1
and should have been
superceded by use of a domainofapplication. It was in conflict
with the validation grammar and appendix C. The single arg form is
not permitted.
>
>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.
>
[JSD] type=function always was allowed, but now it is one of the
officially listed types.
>
>C.2.2.7 (our issue 14-10)
>
>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.
>
[JSD] The signature now allows boolean,. The condition of set
membership should be
explicitly stated as a condition on a bvar as in apply( op ,
bvar(x) , condition( x in C) , ... )
If the apply does not supply a bvar, this can still be written as
apply( op , domainofapplication( set( bvar(x), x in C) ) , ... )
>
>C.2.2.9 (our issue 14-11)
>
>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.
>
[JSD] This has been reworded. and the bvar count is allowed to go to
0. lamda may
also have a domainofapp child, the meaning of which would be to
restrict the domain
over which the new function is defined.
>
>C.2.2.10 (our issue 14-12 - editorial)
>
>use a small circle Unicode character instead of @ in the description.
>
[JSD] fixed.
>
>C.2.2.13 (our issue 14-13)
>
>The property should use Exists as in Forall(y, Exists(x,y=f(x)), y in
>codomain(x))
>
[JSD] fixed.
>
>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.
>
[JSD] fixed. However, we have not added any special
properties.for definitory equivalence
>
>How about this extra example: Forall(f, x in image(f), x in codomain(f)).
>
>C.2.2.15 (our issue 14-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.
>
[JSD]The description has been revised as well as the signature. We
have not moved its position in the document as the grouping of the
items is based on chapter 4. Set identifiers and sets are now allowed.
>
>C.2.2.16 (our issue 14-16) The formal signature allows zero ...
>
[JSD] signature and consistency with chapter 4 [JSD] Fixed.
>C.2.2.17 (our issue 14-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.
>
[JSD] We have elected to stay with algebraic and distinguish
between a standard and "non-standard" use of the notation by
asking the author to use a definitionURL in the non-standard cases.
>
>C.2.3.1 ... routine editorial
>
>C.2.3.4, C.2.3.5 (our issue 14-19)
>
>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.
>
[JSD] fixed as per the discussion of domainofapp at the beginning of
this note and in earlier notes to be (domainofapp,function) ->
algebraic. We chose algebraic over anything as we considered
posets over relations as being outside of k-14 - the nominal
audience - and so best left to extensions.
>
>C.2.3.12 (our issue 14-19 continued )
>
>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].
>
[JSD] fixed as per the general changes for domainofapp
>
>C.2.3.18 (our issue 14-20)
>
>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.
>
[JSD] fixed as per the general changes for domainofapp
>
>C.2.3.19 (our issue 14-21)
>
>The description and the signature are incorrect, and should be rewritten
>from scratch based on the (corrected) text for forall (C.2.3.18).
>
[JSD] fixed.
>
>C.2.3.23 our issue (14-22)
>
>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.)
>
[JSD] fixed.
>
>C.2.3.24 our issue (14-23)
>
>The property is only correct if the type of x and y is specified as
>real. See C.2.3.23.
>
[JSD] fixed.
>
>C.2.4.2 our issue (14-24)
>
>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.
>
[JSD] This was left as binary as it was felt that there were too
many choices for what n-ary might mean.
>
>C.2.4.7 our issue (14-25)
>
>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)?
>
[JSD] fixed.
>
>C.2.5.1 our issue (14-26)
>
>Add signature
>
>(domainofapplication, function) -> anything
>
>which is needed in some examples in this spec (e.g. $\int_D f$).
>
[JSD] fixed as per the general changes for domainofapp
>[ our issue (14-26) continued ]
>
>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.
>
[JSD] fixed as per the general changes for domainofapp. The
"interval" proposal has been discussed elsewhere.
>
>C.2.5.2 our issue 14-27
>
>I remarked in my previous posting that this should perhaps be defined
>more like partialdiff.
>
[JSD] We left this as univariate. We were not want to get into the
possible interpretations and conventions that a multivariate form of
this would mean. As it stands even fairly introductory users will
have not confusion over which to use. Also, given that apply's of
csymbols can use bvar, there is nothing preventing us from
experimenting with various possibilities and at some point moving a
successful model more formally into the spec at some point in the
future.
>
>C.2.5.3 Our issue 14-28
>
>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.
>
[JSD] fixed.
>
>
Received on Thursday, 10 July 2003 10:07:36 UTC