From: Stan Devitt <jsdevitt@stratumtek.ca>

Date: Tue, 25 Feb 2003 19:45:44 -0500 (EST)

Message-Id: <200302260045.h1Q0jiD23997@radical.stratumtek.ca>

To: Bill.Naylor@mcs.vuw.ac.nz (Bill Naylor)

Cc: paul@activemath.org (Paul Libbrecht), www-math@w3.org

Date: Tue, 25 Feb 2003 19:45:44 -0500 (EST)

Message-Id: <200302260045.h1Q0jiD23997@radical.stratumtek.ca>

To: Bill.Naylor@mcs.vuw.ac.nz (Bill Naylor)

Cc: paul@activemath.org (Paul Libbrecht), www-math@w3.org

I thought someone might catch that change in A&S between versions. :-) In 4.1.3 it states that "Each structure has an associated default semantics and there is a mechanism for associating new mathematical definitions with new constructs." In 4.3.2.3 it states that using the definitionURL "overrides" the MathML default semantics." While it is true that the recommendation stops just short of prescribing the content semantics, (if I remember correctly, appendix C is not normative) in my opinion it is still a fairly strong recommendation that if you mean something different you have an obligation to say so. For example, I quote from appendix C where a model for the usage for definitionURL is recommended, <p>The primary role of MathML content elements is to provide a mechanism for recording that a particular notational structure has a particular mathematical meaning. To this end, every content element must have a mathematical definition associated with it in some form. The purpose of this appendix is to provide <emph>default</emph> definitions. (An index to the definitions is provided later in this document.) Authors may adapt the notation to their own particular needs by using mechanisms provided to override these default definitions for selected content elements.</p> My personal interpretation of this is that at very least, you must use a definitionURL if you require something specific especially if different from appendix C. In the absence of a definitionURL, a user or developer could reasonably expect you meant the definitions in appendix C to some degree of rigour. Stan D. > > > On Wed, 26 Feb 2003, Paul Libbrecht wrote: > > > Date: Wed, 26 Feb 2003 00:43:43 +0100 > > From: Paul Libbrecht <paul@activemath.org> > > To: www-math@w3.org > > Subject: Re: Java API for MATHML > > Resent-Date: Tue, 25 Feb 2003 18:44:05 -0500 (EST) > > Resent-From: www-math@w3.org > > > > > > Stan Devitt wrote: > > > > >The content definitions for the arc trig functions > > >used in appendix C were largely based on Abromovitz > > >and Stegun, Section 4.4 -- see, for example, > > > > > >http://www.w3.org/TR/WD-MathML2-20021219/appendixc.html#cdef.arccos > > > > > >and more generally, were chosen to be consistent > > >with OpenMath. > > > > > > > > Actually which version of Abromovitz and Stegun ? > > I hear some noise that the definition of arccot has been changed between > > versions. > > If you check the Description child of CD, you will note that it says: > > "They are defined as in Abromowitz and Stegun (ninth > printing on), with precise reductions to logs in the case of > inverse functions." > > this is a relic of NAHG, so I take no responsiblity ;-) However it seems > to me fairly precise ... no? Anyway as I said in a previous mail check out > transc3 if you want the multivalued functions. > > > MathML having decided not to specify the definition domain... this may > > be a problem, or ?? > > I guess that MathML decided to religate these more 'mathematically > pedantic' issues to some other mechanism viz. OpenMath > > > (hence my request for any new system built with compatibility in mind to > > declare >precisely< its compatibility). > > we can but hope! > > cheers, > > Bill > > > > > Paul > > > > >Received on Tuesday, 25 February 2003 19:32:57 UTC

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