Re: errata and comments, chapters 2 and 4

Stan,

sorry for responding a bit slowly, but I'm swamped with other work these 
days.

Stan Devitt wrote:

>
> Andreas,
>
> Going over your  message on chapter 2 and 4 on May 8th,  I think we 
> have now gone through all the issues.  I have structured this note as 
> a summary of the current status and the outcome on each open issue.  I 
> have included a copy of the original note for completeness. 

Thanks. 

> Thee small editorial changes have all been made except in some 
> instances that boil down to editorial style.  I only discuss here the 
> major points  that are not marked in our records as confirmed closed. 

I agree.  We already went over the others before.

> According to our records, the main items arising from this message 
> that  we have not got confirmation on are:
>
>     1.  proposed deprecation of interval.  (our issue# 13-14)
>
> OUTCOME:  We have elected to keep interval as both a qualifier and a 
> regular object, but have described how to resolve ambiguitie that may 
> arise. 

I think I said in a previous message that I was happy with your 
resolution of this issue.

>     2.  possible values of the type attribute    (our issue# 13-16)
>
> OUTCOME:  We have clarified that the type attribute value is an 
> arbitrary string and so can be, for example, a space or comma 
> separated list of other common values.  We have added a "function" 
> attribute value to the list of known types to help avoiding use of the 
> deprecated fn container name. 

Good.

>     3.  partialdiff   versus diff  structure (our issue# 13-17)
>
> OUTCOME:  We have retained the univariate structure of diff.  This 
> helps to ensure there is no confusion between which notation to use, 
> and having clarified that qualifiers can be used with user defined 
> symbols, the functionality and interpretation you are seeking can be 
> formalized without needing to use diff.  This should be flagged as a 
> candidate for review in the future as some such conventions develop 
> and stabilize. 

As I said in my previous post, I agree with your resolution of this 
issue, both in the sense that it is OK to leave it as-is for the moment, 
and in the sense that it should be left as a candidate for review later.

>     4.  4.2.4       the wording about binary relations. (our issue# 
> 13-20)
>
> OUTCOME:   This wording has been revised along the lines you suggest. 
> We have also made it clear that more than one classification may be 
> possible for an operator. 

Sounds good.

>     5.  4.3.2.5    introduction of a type attribute value to denote 
> nargs.  (our issue# 13-23)
>
> OUTCOME:   Since the type attribute takes arbitrary strings as values 
> this is already permitted in the present spec.  We did not formalize 
> "nargs"  as a possible value as we were wanting to  focus  more on 
> mathematical types than on  structural types;.  More needs to be said 
> on facilitating types and that will appear in a forthcoming note on 
> that topic. 

That's fine.

>     6.  4.4.2.11  ident having  a "domain".  (our issue# 13-30)
>
> OUTCOME:   We did not make any formal change to ident in this regard. 
> We did however follow your suggestions to clarify the use of lambda, 
> in particular, that you may associate a domain with a function so that
>
> <declare>
>   <ci>IDENT</ci>
>   <lambda>
>     <ident/>
>     <domainofapplication><ci type="set">C</ci></domainofapplication>
>   </lambda>
> </declare>
>
> creates just such a named function. 

OK -- but I'm not sure I understand your lambda example above. Shouldn't 
that be

<declare>
  <ci>IDENT</ci>
  <lambda>
      <domainofapplication><ci type="set">C</ci></domainofapplication>
      <ident/>
  </lambda>
</declare>

(aren't qualifiers supposed to precede arguments? The generalized 
quantifier here is the lambda, which means there is no operator in a 
lambda.)  Also, I believe I was thinking more along the lines of 
phrasing this particular example as follows (with an explicit bvar), 
although that doesn't really matter much:

<declare>
  <ci>IDENT</ci>
  <lambda>
      <bvar> <ci>x</ci> </bvar>
      <domainofapplication><ci type="set">C</ci></domainofapplication>
      <apply><ident/> <ci>x</ci></apply>
  </lambda>
</declare>

>     7.  4.4.2.16  degenerate cases for piecewise  (our issue# 13-32)
>
> OUTCOME:   We have relaxed these constraints so that the degenerate 
> cases may now occur.

Good.

> Once again, confirmation from you that we have addressed these major 
> points will help us to track these items properly.

As far as I remember, this indeed covers all the major points that I 
raised. I'm looking forward to seeing the outcome of this round of 
revisions to MathML 2.0.

Going through my original message below, I believe there is only a 
single minor editorial point that I don't recall having seen an explicit 
resolution for yet; in your first reply to that message I think you 
specifically deferred it. Here it is:

 >
 >Appendix I.2, last sentence.  There is a grammatical error in this 
sentence.
 >

Thanks for doing all the work on this!

 -- Andreas

>
>
> Thanks in advance,
>
> Stan Devitt
> Math Working Group.
>
> > errata and comments, chapters 2 and 4
> >
> > From: Andreas Strotmann (Strotmann@rrz.uni-koeln.de)
> > Date: Thu, May 08 2003
> >
> >Message-ID: <3EBA6CCD.10306@rrz.uni-koeln.de>
> >Date: Thu, 08 May 2003 16:42:21 +0200
> >From: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
> >To: Andreas Strotmann <Strotmann@rrz.uni-koeln.de>
> >CC: www-math@w3.org
> >Subject: errata and comments, chapters 2 and 4
> >
> >
> >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.
> >
>
> Discussions have been added in the text to
>
> >
> >
> >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.
> >
> [JSD]    These degenerate cases are now allowed.
>
> >
> >
> >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 Friday, 11 July 2003 10:41:14 UTC