Re: Java API for MATHML

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