MathML 2.0, second edition
Last Call Disposition of Comments

Issue 1-1. Status: closed

From Bill Naylor

I have a comment on the second exmaple in section 4.2.5.1:
there are three csymbol elements, all pointing to

http://www.openmath.org/cd/setname1.ocd

this is ambiguous as it stands, since that CD holds definitions of six
symbols. The example would be more accurately (unambiguously) stated as:

-----------------------------
The next example encodes "for all x in N there exist prime numbers p, q
such that p+q = 2x".

<apply>
  <forall/>
  <bvar><ci>x</ci></bvar>
  <condition>
    <apply><in/>
          <ci>x</ci>
          <csymbol encoding="OpenMath"
            definitionURL="http://www.openmath.org/cd/setname1.ocd#N"/>
        </apply>
  </condition>

  <apply><exists/>
     <bvar><ci>p</ci></bvar>
     <bvar><ci>q</ci></bvar>
     <condition>
       <apply><and/>
          <apply><in/><ci>p</ci>
            <csymbol encoding="OpenMath"
              definitionURL="http://www.openmath.org/cd/setname1.ocd#P"/>
          </apply>
          <apply><in/><ci>q</ci>
            <csymbol encoding="OpenMath"
              definitionURL="http://www.openmath.org/cd/setname1.ocd#P"/>
          </apply>
          <apply><eq/>
              <apply><plus/><ci>p</ci><ci>q</ci></apply>
              <apply><times/><cn>2</cn><ci>x</ci></apply>
          </apply>
        </apply>
      </condition>
  </apply>
</apply>
-----------------------------

as it stands, it is implying that http://www.openmath.org/cd/setname1.ocd
refers to some function which takes a string as argument and returns a
set.
    

I think that the existing examples are technically correct (The
semantics of definitionURL are sufficiently flexible to allow a single
URI to cover different symbol definitions) however it would be clearer
if they were separated.

You suggested

 definitionURL="http://www.openmath.org/cd/setname1.ocd#N"

Which is the form used already in some of the OM -> MathML conversion
scripts, however openmath.org serves .ocd files as text/plain so that
you get a "source view", and the browser doesn't scroll to the
definition of N if you follow that link.

We propose to use

 definitionURL="http://www.openmath.org/cd/setname1#N"

without any explict extension as an abstract identifier for this symbol.
The server at openmath.org (now!) will redirect that to the html form

http://www.openmath.org/cd/setname1.html#N

where the fragment identifier #N will work as expected and scroll the
view to the symbol N.
    

Proposed resolution: Spec fixed

We have elected to go with a slightly modified version of your
suggestion, namely using

  definitionURL="http://www.openmath.org/cd/setname1#N"/>

Due to recent changes on the Openmath site,  the ".ocd" file
extension is no longer necessary.  This URL now is valid
and addresses identifies a specific dictionary entry.

Issue 2-1. Status: closed

From Bill Naylor

in section 5.3.4 there is an example which has an incorrect
xlink:href attribute (the first OMS in the encoding="OpenMath" child):
[...]
<om:OMS name="and" cd="logic1"
        xlink:href="#xpointer(id('E'))" xlink:type="simple"/>
                                 ^^^ should be 'E.2'
    

Proposed resolution: Spec fixed

Issue 3-1. Status: closed

From Bill Naylor

The third example in section 5.4.3:

<semantics>
   <ci><mo>rank</mo></ci>
   <annotation-xml encoding="OpenMath">
      <OMS name="rank" cd="linalg3" xmlns="http://www.openmath.org/OpenMath"/>
   </annotation-xml>
</semantics>

should be:

<semantics>
   <ci><mo>rank</mo></ci>
   <annotation-xml encoding="OpenMath">
      <OMS name="rank" cd="linalg4" xmlns="http://www.openmath.org/OpenMath"/>
   </annotation-xml>
</semantics>
    

Proposed resolution: Spec fixed

Spec fixed as suggested

Issue 4-1. Status: closed

From Simon Pepping

I believe the restriction of the content model of mmultiscripts in this DTD
is not as precise as it could be:

  <!ENTITY % prscrPresExpression " (
  (%Presentation; | %ContInPres;|%none.qname;)*,
  (%mprescripts.qname;,(%Presentation; | %ContInPres;|%none.qname;)*)?
)">

It does not express the restriction that there should be an even number of
postscripts and of prescripts. I believe this content model expresses it
more precisely:

  <!ENTITY % prscrPresExpression " (%onePresExpression;,
  ((%onePresExpression;|%none.qname;),(%onePresExpression;|%none.qname;))*,
  (%mprescripts.qname;,
  ((%onePresExpression;|%none.qname;),(%onePresExpression;|%none.qname;))*)?
)">
    

Proposed resolution: Spec fixed

Spec fixed as suggested

Issue 5-1. Status: closed

From Andreas Strotmann

4.2.3.2:

I would like to suggest removing one line from the example quoted below 
from section 4.2.3.2, namely, the line containing the bvar qualifier:

" It is also valid to use qualifier schema with a function not applied 
to an argument. For example, a function acting on integrable functions
on the interval [0,1] might be denoted:
<fn>
<apply>
<int/>
<bvar><ci>x</ci></bvar>
<lowlimit><cn>0</cn></lowlimit>
<uplimit><cn>1</cn></uplimit>
</apply>
</fn>
"

Proposed resolution: spec fixed

As you have noted elsewhere in your comments, this is actually
intended to be a curried expression, and not {\int_0^1 1 dx}

This has been clarified in the remarks by adding an example of how to 
accomplish  the same thing without the deprecated fn by using a lambda 
expression.
[...]
In the end, we have removed the bvar as you suggested.

Our main concern was to
retain the notion of curried expressions and agree that
it leaves fewer open questions if we use the functional
form of the int operator.  I have attached a rewording
of that example below. Note that it now includes an
alternative form that avoids the whole issue of the
fn element.

Issue 5-2. Status: closed

From Andreas Strotmann

I found that Maple quite reasonably interprets the apply element of the 
example as it stands now as $\int_0^1 dx$, which evaluates to 1.

The problem is that the correct way to represent the concept of 
integrals over a particular interval is along the lines of the example 
in section 4.4.2.15 (Domain of Application):

"The integral of a function f over an arbitrary domain C .
<apply>
  <int/>
  <domainofapplication>
    <ci> C </ci>
  </domainofapplication>
  <ci> f </ci>
</apply>
"

Proposed resolution: spec fixed

In several places throughout the text we have clarified that the most 
general qualifier is the domainofapplication an that the others should 
be thought of as abbreviations.  We have made this systematic throughout 
the text across various examples that you refer to in your note that 
were artificially restricte  to one or other of the shortened forms so 
that qualifiers are now treated more uniformly.  Note that this does not 
break any legacy data.

We did not deprecate the shorthand notations as they
serve two other important roles.

1.  New users looking for  a representation of \int_0^1 f(x) dx,
more quickly recognize the short form with uplimit and lowlimit
and may not be prepared to formalize this into a domain of application.
(It matches how they are used to writing their mathematics.)

2.  Each of the shortened forms maps naturally to a particular
presentation.  (e.g., upper and lower bounds with bound variables,
or intervals to {\int_0^1 f } or  bvar and condition of set
membership in C to {\int_{x\inC} f(x) dx }. )

Issue 5-3. Status: closed

From Andreas Strotmann

using a unary function as an argument to the integral operator.  The way 
the current example that I suggest fixed here stands, variables x in the 
argument to such a function would be crossing a variable binding barrier 
in a rather peculiar way that I don't think any semantics formalism 
could possibly allow in a systematic fashion.

Proposed resolution: spec changed

Several examples discussing how domainofapplication and the
other representations of domain of integration are handled.

This representation corresponds roughly to the common usage
{\int_C f} and the notion of integrating a "function" over
a domain.

The underlying problem aluded to here is how to decide which
bound variable of the domain corresponds to which bound variable
of the integral and it surfaces in examples where the the
domainofapplication and the function are actually defined.

We have clarified this by using your suggestion of viewing the
domain as an "implicit" cartesian product in which the order
of the bound variables maps directly to the order of the
terms in the cartesian product.

Issue 5-4. Status: closed

From Andreas Strotmann

4.4.2.15:

I just realized that domainofapplication is not currently listed as a 
qualifier (as I had assumed) but as a regular element.  I don't think 
that that is a good idea -- it clearly has just as special a semantics 
as all the other qualifier elements, and should be a qualifier just like 
them.
    

Proposed resolution: spec fixed

In chapter 4, the only place where the qualifiers are listed as such
is in a table. (The same holds true for appendix C.)  This term
was missing from the qualifier rule in the validation grammar
(appendix B) and this has been fixed.

Text has also been added in several places to better clarify
the usage and interaction of the qualifiers and is discussed
in more detail in the detailed answers to one of your other
queries on this topic.
    

Issue 6-1. Status: closed

From Simon Pepping

attribute minlabelspacing for element mtable is not listed in the DTD
    

Proposed resolution: spec fix

Issue 6-2. Status: closed

From Simon Pepping

The example in section 3.5.5.8 has an error: The groupalign attribute
should be a list of lists, i.e., it should be enclosed in braces.
    

Proposed resolution: spec fix

Fixed.

Issue 6-3. Status: closed

From Simon Pepping

If I interpret the spec on alignments correctly, it is not possible to skip
an alignment group in a group-alignment list. Then, if a malignmark is used
in some alignment group, it probably has priority over the value listed for
this alignment group in the group-alignment list. I did not find a reference
to this case in the spec; it might be useful to add a description.

An example that illustrates the point:

<mml:math>
<mml:mtable groupalign="{right}">
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:maligngroup/>
  <mml:mi>a</mml:mi>
  <mml:mo>+</mml:mo>
  <mml:mi>b</mml:mi>
<mml:malignmark/>
  <mml:mo>=</mml:mo>
  <mml:mn>1</mml:mn>
</mml:mrow>
</mml:mtd>
</mml:mtr>
<mml:mtr>
<mml:mtd>
<mml:mrow>
<mml:maligngroup/>
  <mml:mi>a</mml:mi>
  <mml:mo>-</mml:mo>
  <mml:mi>b</mml:mi>
</mml:mrow>
</mml:mtd>
</mml:mtr>
</mml:mtable>
</mml:math>
    

Proposed resolution: spec fix

Section "3.5.5.7 Inheritance of groupalign values" does actually
address this.  However, I added a sentence giving this specific case
as an example of the general rule.

Issue 7-1. Status: closed

From Bill Naylor

The list of available content elements in section 4.4 (arithmetic, algebra
and logic) includes a link to 'exp', this also belongs to 'elementary
classical functions', I think the first is in error
    

Proposed resolution: Spec fixed

Fixed.

Issue 8-1. Status: closed

From Gustavo J A M Carneiro

 When describing the <mo> attributes, the MathML reference indicates
this in a table:
  symmetric true | false set by dictionary (true)

(this is in section 3.2.5 Operator, Fence, Separator or Accent (mo))

  However, the suggested operator dictionary, in "appendix F Operator
Dictionary (Non-Normative)", does not include a symmetric attribute.
    

The listing in Appendix F does actually specify stretchy="true" for
the entries where it should be true.  However, to save space, the
table leaves out attributes that have the same value as the default
for operators not in the disctionary.  The text at the start of
Appendix F says:

> Any attribute not listed for some entry has its default value, which
> is given in parentheses in the table of attributes in Section 3.2.5
> Operator, Fence, Separator or Accent (mo). 

If you look in 3.2.5, you will see that the default value for
"stretchy" listed in parentheses is false.  Hence, the Operator
Dictionary in Appendix F only lists the cases where stretchy="true".

	Are you not confusing "stretchy" with "symmetric"?  My problem is that
the symmetric attribute is not specified for any operator.  I realize it
has a default value of 'true', therefore I conclude that symmetric=true
for all operators.  Maybe this is intentional, but I find it a little
strange that *all* operators are symmetric by default...

My apologies.  You are correct.  I was confusing stretchy with
symmetric.

However, I believe your interpretation is correct -- by default, all
operators are symmetric.  

I suppose there could be some exceptional case that I'm overlooking,
but in practice, I have only used symmetric="false" in two cases:

1) Matrix multiplication of non-square matrices:

  |a b| |A B C|   |x y|
  |c d| |D E F| = |z w|
  |e f|

  This is hard to convey as ASCII art, but what one wants to avoid is
  something like:


  |a b| |A B C|   |x y|
  |c d| |D E F| = |z w|
  |e f| |     |   |   |

2) Complicated, deeply-nested expressions that are highly unsymmetric
   around the baseline, where symmetric parentheses look odd.

There are probably more, but these are the only two cases I've
encountered.  However, both of them are clearly exceptional cases --
I'm using symmetric="false" to fix a rendering that looks odd
otherwise.  So the default is still true for all these fence
characters.

Proposed resolution: No change

Issue 10-1. Status: closed

From Tim Boland

I notice that CSS1 and CSS2 are in
    acknowledgements; there is a CSS2.1 coming along (not yet a
    rec).
    

Proposed resolution: no change

we went through the
references of the spec and considered referencing CSS 2.1, but in the end
decided to restrict the references to recommendations.

NOTE: the original submitted did not acknowledged this decision, after 3 
weeks since the WG's response. The WG decided to close the comment, 
as this is judged to be a minor point.

Issue 11-1. Status: closed

From I18N WG

Front page:

"Please refer to the errata for this document, which may include some 
normative corrections."

According to the new process document (now in review), errata
pages are not normative.
    

Proposed resolution: No change

We copied the mandatory markup from the W3C publication rules [1]:

[[
If a Recommendation, immediately after the editors/authors' names, the
link to an errata document must be made with the following markup:

<p>Please refer to the <a
href="http://www.w3.org/..."><strong>errata</strong></a> for this
document, which may include some normative corrections.</p>
]]

[1] http://www.w3.org/Guide/pubrules
    

Issue 11-2. Status: closed

From I18N WG

Overall: It would be extremely nice to have an index of elements
and attributes. Given all the technology used for producing the
spec, this shouldn't be a problem at all.
    

Proposed resolution: Spec fixed

A new appendix contains an index of element and attributes

Issue 11-3. Status: closed

From I18N WG

3.2.8 String Literal (ms)

"In practice, non-ASCII characters will typically be represented by entity 
references."

This sentence should be removed. It is technologically biased
(there are enccodings and tools that don't need entity references),
and it is also biased with regards to language. E.g. Japanese
mathematician would never represent Japanese (i.e. non-ASCII)
characters with entity references.
    

Proposed resolution: Spec fixed

This sentence has been removed

Issue 11-4. Status: closed

From I18N WG

3.2.9 Adding new character glyphs to MathML (mglyph)

We have earlier complained about this: "character glyph" is
not a term that we know, nor is it defined in this spec, nor
should it be used, because it is highly confusing. The text
of the section now mostly manages to avoid it. If you want
an easy way out, substitute "character glyphs" with
"characters/glyphs". This at least makes it clear that
these are two different things.

The wording could be improved, but I think characters/glyphs would
actually be worse as it implies two different things. mglyph
is for accessing glyphs (representing characters) from fonts.
as opposed to the mchar element which was part of some of the mathml 2
WDs but removed before the  rec, which was an element taking a name
representing a character (as an alternative to using entities/character
data).

characters/glyphs was just a very quick shot, sorry.
I'm sure you can do better.

Proposed resolution: Spec fix

Fixed.

Issue 11-5. Status: closed

From I18N WG

4.4.11.1 Annotation (annotation)

(and same for 4.4.11.3 XML-based annotation (annotation-xml) )

 >>>>
The annotation element takes the attributes definitionURL and encoding that 
can be used to override the default semantics. Only the encoding attribute 
is required whenever the semantics remains unchanged.
 >>>>

It would be good to have a clear explanation of 'encoding' here,
so that people don't confuse it with the 'encoding' pseudo-attribute
in the XML declaration.



    

Proposed resolution: Spec fix

You were concerned that the encoding attribute (used on several content
mathml elements) could be confused with the text encoding of the
document as used in an xml declaration encoding  pseudo-attribute.

My initial reply indicated that we could add a clarifying comment,
although it turns out that this slipped through the cracks
and (should you have looked at our internal draft) this didn't get done.

We have just amended 4.3.2.4 where the encoding attribute is introduced
adding the sentence

  Note this is unrelated to the text encoding of the document as specified
  for example in the encoding pseudo-attribute of an XML declaration.

Issue 11-6. Status: closed

From I18N WG

6.1 Introduction

 >>>>
It did not fall naturally within the purview of developing a specification 
enabling mathematics to be used with HTML and producing a DTD for the 
Working group this to worry about more than the entities allowed in the DTD.
 >>>>

"this" is weird.

More general, the I18N WG has on various occasions requested that the
introduction in chapter 6 be seriously shortened to make sure the document
stays a spec rather than a historical account of a spec's history.
    

    This text was heavily edited in this 2nd edition to remove most
references to the use of "proposed" characters (since the main
motivation for having a 2nd edition is that these characters are now
mostly standardised (and we will just have to learn to live without the
remaining ones which didn't make it into Unicode). However you've shown
a few places where such references were missed. I'm sure this can be
easily fixed.

Proposed resolution: fixed

"this": FIXED: A typo from another change.

The text has been shortened quite a bit.  However, the presence of
explanatory text, to outline the situation to readers and implementors
who may not be aware of reasons for what they find strange, was
intentional.  By and large the MathML spec has been felt to read quite
well.  The spec, I suggest, has enough dry technical detail that
few will think it anything else.  A history of how the spec came to
be would require a lot more room.

Issue 11-7. Status: closed

From I18N WG

"While a long process of review and adoption by UTC and ISO/IEC of the 
characters of special interest to mathematics and MathML is now  complete 
(Unicode Work in Progress) there remains the possibility of some further 
modification of the lists of characters accepted, of the code assignments 
for those adopted, or of the names given them by Unicode. To make sure any 
possible corrections to relevant standards are taken into account, and for 
the latest character tables and font information, see the W3C Math Working 
Group home page and the Unicode site."

This is highly misleading. There is a very strong commitment by
Unicode and ISO to not change any codepoints or names. The characters
referenced in the spec to our knowledge all have been fully
accepted, and any language such as the above suggesting there
will be further changes is highly confusing and misleading and
should be removed.
    

Proposed resolution: No change

As you are no doubt aware, although the invariability of a character
standard like Unicode is as desirable as ever, there seem to be changes
afoot again that will affect both mathematical encoding and W3C.
Unfortunately we do not have a situation in which someone can say,
as in the story of Daniel
"O king, establish the decree and sign the writing, that it
be not changed, according to the laws of the Medes and Persians
which altereth not."
Daniel 6:8-9

Thus it seems reasonable to retain a weakened version of the text above.
The reference to the Unicode Work in progress has been moved and clarified.

Issue 11-8. Status: closed

From I18N WG

"The parenthetical notation beginning with U+ is one recommended by Unicode 
for referring to Unicode characters [see [Unicode], page xxviii]."

What about this notation is parenthetical? Proposal: remove 'parenthetical'.
'is one' -> 'is the one'; also, just introduce the notation, and then
avoid to list the same numbers twice, once without and once with U+.
    

Proposed resolution: Spec fix

The notation is in parentheses; that's what parenthetical means.
CHANGED for clarity TO
'notation, just introduced in parentheses,'

<< 'is one' -> 'is the one';
CHANGED per grammar To
'is that'

<< also, just introduce the notation, and then
<< avoid to list the same numbers twice, once without and once with U+.
The redundancy was felt to be of possible assistance to those not
already well familiar with Unicode notations for character codes.
    

Issue 11-9. Status: closed

From I18N WG

6.2.1 Unicode Character Data

 >>>>>>>>
     * Using characters directly: For example, an A may be entered as 'A' 
from a keyboard (character U+0041J). This option is only available if the 
character encoding specified for the XML document includes the character. 
Most commonly used encodings will have 'A' in the ASCII position. In many 
encodings, characters may need more than one byte. Note that if the 
document is, for example, encoded in Latin-1 (ISO-8859-1) then only the 
characters in that encoding are available directly. Unfortunately, most 
mathematical symbols may not be encoded as character data in this way.
 >>>>>>>>

The last sentence is misleading. Using UTF-8 or UTF-16, the two only
encodings that all XML processors are required to accept, mathematical
symbols can be encoded as character data.
    

The intention of that bit was to highlight that using latin-1 (for
example) may not be the best idea as it limits direct access to
most of the mathematical characters, and (by implication authors may
want to consider using utf*). You clearly didn't read it that way, so
perhaps explictly mentioning utf.. here would clarify things.
    

Yes, it was unclear what 'this way' referred to. What about something
like:

for example, encoded in Latin-1 (ISO-8859-1) then only the
characters in that encoding are available directly, which excludes
most mathematical symbols. Encodings such as UTF-8 and UTF-16
can directly encode all characters in Unicode.

Proposed resolution: Spec fixed

As mentioned by David Carlisle
http://lists.w3.org/Archives/Public/www-math/2003May/0029.html
this didn't get across a point we intended.  We can adopt your
sentence:

LAST SENTENCE CHANGED TO
Using UTF-8 or UTF-16, the only two encodings that all XML
processors are required to accept, mathematical symbols can
be encoded as character data.

Issue 11-10. Status: closed

From I18N WG

 >>>>
By using Character references it is always possible to access the entire 
Unicode range.
 >>>>

'Character references': inconsistent capitalization.
    

Proposed resolution: Spec fix

FIXED

Issue 11-11. Status: closed

From I18N WG

6.2.2 Special Characters Not in Unicode

 >>>>
In these cases one may use the mglyph  element for direct access to a glyph 
from some font and creation of a MathML character corresponding.
 >>>>

corresponding to what?
    

Proposed resolution: Spec fix

To the glyph.  The idea is that if you have created a glyph in a font
for mathematical notation not in Unicode, then there's a way to use
it like a character.  For instance, if the overcrossing drawn in
knot theory is used in a discussion of knotting of DNA then it is
quite possible that it may need to occur in an equation.  <mglyph>
is what you use to do this.

CHANGED TO
creation of a MathML substitute for the corresponding character.

Issue 11-12. Status: closed

From I18N WG

6.2.3 Mathematical Alphanumeric Symbols Characters.

there should not be a dot after the title
    

Proposed resolution: Spec fix

Fixed

Issue 11-13. Status: closed

From I18N WG

 >>>>
  The new Mathematical Alphanumeric Symbols provided in Unicode 3.1
 >>>>

remove 'new'. Otherwise, the spec already looks outdated
before it is approved.

Proposed resolution: closed

The characters expressly introduced by Unicode to facilitate
mathematical formulas certainly are new.  They are the solution
that was found for a specific need in mathematical markup.
It could conceivably have happened that only a few special math
variant markers were introduced, but it did not.

CHANGED
'new' ===> 'additional'

Issue 11-14. Status: closed

From I18N WG

 >>>>
... in contrast to the Basic Multilingual Plane (BMP) which has been used 
by Unicode so far.
 >>>>

remove temporal context ('so far')

Proposed resolution: Spec fix

The addition of many new (additional) planes was an important
change for Unicode.

'which has been used by Unicode so far'
CHANGED TO
'which was originally the entire extent of Unicode'

Issue 11-15. Status: closed

From I18N WG

 >>>>
For example, a Mathematical Fraktur alphabet is being added, and the code 
point for Mathematical Fraktur A is U1D504.
 >>>>

'is being added' seems to refer to some activity that is now complete.
Please update. Also, U1D504 -> U+1D504

Proposed resolution: Spec fix

Wrong tense and wrong code FIXED

Issue 11-16. Status: closed

From I18N WG

6.2.4 Non-Marking Characters

 >>>>
Some characters, although important for the quality of print or alternative 
rendering, do not have glyph marks that correspond directly.
 >>>>

correspond to what?

Proposed resolution: Spec fix

ADDED 'to them'

Issue 11-17. Status: closed

From I18N WG

 >>>>
The Universal Character Set (UCS) of Unicode and ISO 10646 continues to 
evolve, see Section 6.4.4 Status of Character Encodings. A small number of 
the changes recently introduced, relative to those resulting from the needs 
of Asian languages, are those designed exactly to facilitate the use of 
Unicode by the 'equation-writing' community. This specification is written 
on the assumption that the code assignments suggested to ISO/IEC 
JTC1/SC2/WG2 by the UTC will be confirmed as they are in public draft forms 
of Unicode 3.1 and 3.2. As before, we can only reiterate that for latest 
developments on details of character standards as far as they influence 
mathematical formalism the home page of the W3C Math Working Group should 
be consulted.
 >>>>

This seems to be totally outdated. Also, http://www.w3.org/Math/workingGroup
does not provide any relevant info. As text such as this has appeared
in older versions, http://www.w3.org/Math/workingGroup should contain
such info, even if it is just to say that all characters in question have
been approved in the meantime.
    

Proposed resolution: Spec change

This is a piece of text that should have been excised and so we have
a new shortened version (see below).  The comments about the character
information that ought to be found on the Math WG page (or IG page
later perhaps) are quite right.   It is intended to keep such
information on updates there.

NEW VERSION ==>

The Universal Character Set (UCS) of Unicode and ISO 10646 continues to
evolve, see Section 6.4.4 Status of Character Encodings.  At the time
of writing the standard is Unicode 4.0.  As before, we can only reiterate
that for latest developments on details of character standards as far as
they influence mathematical formalism the home page of the W3C Math
Activity should be consulted.

Issue 11-18. Status: closed

From I18N WG

6.3 Character Symbol Listings

 >>>>
  The characters are listed by name, and sample glyphs provided for all of 
them. Each character name is accompanied by a code for a character grouping 
chosen from a list given below, a short verbal description, and a Unicode 
hex code drawn from ISO 10646, now extended in accordance with the proposal 
forwarded by the UTC to ISO/IEC WG2 in March 2000.
 >>>>

outdated, please fix

Proposed resolution: Spec fixed

UPDATED

Issue 11-19. Status: closed

From I18N WG

6.3.1 Special Constants

 >>>>
These have been accorded new Unicode values.
 >>>>

'have been accorded': remove temporal reference

Proposed resolution: Spec fix

'have been accorded new'
===>
'now have'

Issue 11-20. Status: closed

From I18N WG

6.3.4 Negated Mathematical Characters

 >>>>
Note that it is the policy of the W3C and of Unicode that if a single 
character is already defined for what can be achieved with a combining 
character, that character must be used instead of the decomposed form. It 
is also intended that no new single characters representing what can be 
done by with existing compositions will be introduced.
 >>>>

There should be an explicit mention of NFC, with a reference to Unicode
Standard Annex #15.

Proposed resolution: Spec fixed

DONE Text and reference added

Issue 11-21. Status: closed

From I18N WG

6.3.6 Mathematical Alphanumeric Symbols

 >>>>
Most of these characters come from the additions to Plane 1, however a few 
characters (such as the double-struck letters N, P, Z, Q, R, C, H 
representing common number sets) were already present in Unicode 3.0 and 
retain their original positions.
 >>>>

This is again more version/history-oriented than necessary. What about:

Most of these characters are in Plane 1, except for a few characters (such 
as the double-struck letters N, P, Z, Q, R, C, H representing common number 
sets) which are in the BMP.

As I say above most of your comments about "future" references to
Unicode 3.1 and 3.2 I accept but in this case I think that the
historical perspective is useful. Your re-wording tries to make it seem
perfectly natural that these characters should be out of sequence,
whereas the holes in the plane 1 block are a regrettable and potentially
confusing feature, and only make sense at all if some of the history as
to why they are there is given.

I didn't try to make this sound perfectly natural. I just tried to
just state the facts.


>whereas the holes in the plane 1 block are a regrettable

We might agree on 'regrettable', but that doesn't belong in
the spec.


>and potentially
>confusing feature, and only make sense at all if some of the history as
>to why they are there is given.

Well, adding 'for historic reasons' at the end of the above
sentence would probably do the job, in that it tells people
not to search for deeper reasons. What's important for
people is the 'watch out' warning. People interested in
history can find it in various places on the Web.

Proposed resolution: No change

It doesn't seem essential to excise the history here, and it helps
some to understand the context.

Issue 11-22. Status: closed

From I18N WG

6.4.2 Fewer Non-marking Characters

 >>>>
It used to be in MathML 1.0 that there were a number more non-marking 
character entities listed.
 >>>>

'It used to be' reads like 'once upon a time'. But this is a spec, not
a fairy tale. What about:

MathML 1.0 contained a small number of non-marking character entities that
have been removed in MathML 2.0.
    

Proposed resolution: No change

I suppose the suggested revision is more machine-friendly.  I see no
difficulty with the other, whether or not this spec is a 'fairy tale',
as some have turned out to be for all their technical writing.

Issue 11-23. Status: closed

From I18N WG

6.4.4 Status of Character Encodings

This section needs serious rework. Some of the (updated) text is speaking
about events in 2001. The section simply should say that earlier
versions may have mentioned that different characters were in different
stages of adoption in the standards process, but that all characters
now in the spec are fully standardized. This is the message that
we need to get out, and this is the way to avoid that the spec
looks silly in a few years.
    
Even with the good will shown to the mathenatical community by the Unicode 
process a small number of characters of special interest to some may not 
yet have been included. The obvious solution of avoiding their use may not 
satisfy all. For these characters the Unicode mechanism involving Private 
Use Area codes could be deployed, in spite of all the dangers of confusion 
and collisions of conventions this brings with it. However, this is the 
situation for which mglyph was introduced.
 >>>>

This paragraph should be rewritten and shortened, if it belongs
into this section at all. It is particularly important to us
that mention of the private use area is removed. What about:

To refer to symbols not included in Unicode, please use the <mglyph>
element.
    

Proposed resolution: Spec change

Why is it so important the I18N that the existence of the PUA,
which is a recorded part of the USC and 10646 be denied?  It is
part of a real standard.  It is not being recommended here, but
its existence is worth a warning.

A REVISED VERSION version now ends with

"However, this is the situation for which mglyph was introduced.
The use of <mglyph> is recommended to refer to symbols not included
in Unicode. "

Issue 11-24. Status: closed

From I18N WG

A.1 Use of MathML as Well-Formed XML

 >>>>
The document should be encoded in an encoding (for example UTF-8) in which 
al needed characters may be encoded as character data,...
 >>>>

al -> all

Finally UTF-8 is mentioned. Great!
    

Proposed resolution: Spec fix

Fixed.

Issue 11-25. Status: closed

From I18N WG

 >>>>
However, in many circumstance,
 >>>>

circumstance -> circumstances; rest of this paragraph needs some
work too, e.g. "specification, Following" -> "specification. Following";
"the a schema validating processor schema" ->
"a schema validating processor"
    

Proposed resolution: Spec fix

Fixed.

Issue 11-26. Status: closed

From I18N WG

A.2.2.2 Plane 1 Characters

As discussed earlier, what this section tries to do
(to provide workarounds for non-compliant XML implementations)
is unacceptable. This is even more so in that the problems in
IE, according to our knowledge, have been fixed. This section
should be removed, and the corresponding DTD fragments fixed
to eliminate the "plane1D" parameter entity.
    

IE 6 SP1 did finally fix the problem in IE6 if you have IE6 SP1.
Of course there are thousands (millions?) of copies of IE6 still out
there. James Clark's nsgmls also has the same restriction (although 
onsgmls does now work with characters out of the BMP I believe).

The MathML DTD uses plane 1 characters, but I see nothing wrong with
giving end users an option not to do that. If they are using a system
that is crippled in this way, removing this feature from the DTD will
not fix their application and does not mean that they can no longer
do the re-mapping, it just means that they will have to redefine half a
dozen parameter entities (for the affected entity sets) to point to some
definition that works on their system penalising end users in this way
doesn't seem particulary useful.

I expected to find information about this on the MathML home
page. Getting the message out to use SP1 and onsgmls is really
important. This is much more efficient than to keep the spec
the way it is. PLEASE GET THIS MESSAGE OUT LOUDLY AND CLEARLY.

Before these fixes, there was a somewhat justified fear that
adherence to standards would delay the spread of MathML to
an undue extent. This is no longer justified.

>The MathML DTD uses plane 1 characters, but I see nothing wrong with
>giving end users an option not to do that.

There would be a lot wrong with that. First, W3C would acknowledge
that it is okay to have non-conforming XML processors, and would
encourage users to use them. A lot of experience over the last
few years has shown that unfortunately, users don't need any
encouragement to do this. We need to encourage them to do the
right thing.

Second, redefining the entities to point to the PUA changes the
infoset of the document. As soon as that document goes through
some kind of advanced processing (e.g. XSLT), these changes
are frozen. The resulting document will not be understood by a
conforming MathML processor.


>If they are using a system
>that is crippled in this way, removing this feature from the DTD will
>not fix their application and does not mean that they can no longer
>do the re-mapping, it just means that they will have to redefine half a
>dozen parameter entities (for the affected entity sets) to point to some
>definition that works on their system penalising end users in this way
>doesn't seem particulary useful.

As far as I see, if a document comes in that points to the correct
DTD (with the 'correct' parameter entity), then such a document won't
work on a nonconforming system. So the user has change something
anyway before it will work. Whether this is adding a parameter entity
definition or changing the location of the DTD doesn't seem to make
too much of a difference for the user. So the clean solution is to
produce a DTD with only the correct stuff (without the parameter entity)
for the spec, and have people with nonconforming systems point to a
different DTD, and mention that on the homepage, but not in the spec.
The way it should be mentioned on the homepage is:

Question: I'm using IE, and have problems with MathML. What to do?
     1) Upgrade to IE6 SP1 (or later)
     2) if that doesn't work, change the reference to the DTD in the file
        to this older one: ...

(and same for sgmls).

In the internal version of appendix A this section has been deleted
and this plane1 -> BMP mapping feature is no longer used in the
xhtml+mathml dtd so it will use the same plane 1 definitions as the
mathml dtd. So the next release of the spec and DTD should address this
comment.

There are currently few if any applications that can use these
characters, but we accept your point that the spec itself should be
describing the standard situation not any temporary workaround that may
be required.

First, you say "There are currently few if any applications that
can use these characters". What applications are you speaking
about? Both IE and nsgmls have been fixed, and these are the
only applications with these problems that we are aware of.

Second, I just had a look at
http://www.w3.org/TR/2003/WD-MathML2-20030411/isoamsa.html.
Some of the glyphs come with boxes around them, and for some
others, there is just a gray box. I'm not sure there is
a need anymore to distinguish different classes of characters.

  First, you say "There are currently few if any applications that
  can use these characters". What applications are you speaking
  about? Both IE and nsgmls have been fixed, and these are the
  only applications with these problems that we are aware of.

They were the two better known applications that would fail to parse
the mathml dtd but most end users probably have a higher level of
expectation for these characters than that they survive parsing.

I don't know of any currently freely available fonts that are set
up with tables so that characters in these positions render as
specified. People sometimes quote the code2001 project but 
http://home.att.net/~jameskass/code2001.htm
still says of mathematics:

   In this version, the special letter forms for Mathematics are (still)
   not completed, and many of them are wrong, rough, or inappropriate.


  Second, I just had a look at
  http://www.w3.org/TR/2003/WD-MathML2-20030411/isoamsa.html.
  Some of the glyphs come with boxes around them, and for some
  others, there is just a gray box. I'm not sure there is
  a need anymore to distinguish different classes of characters.


The grey box is "none.png" which is a link the stylesheet creates
if a better character image isn't supplied. I hope to generate some
more images now the actual code assignments are stable, once we've
finished handling last call comments to the text of the spec.
Similarly the images with boxes are older images from the mathml-1 spec
that just have a border within the image. Hopefully we'll be able to
regenerate those as well sometime, but they are lower priority than the
images that are missing.

>I don't know of any currently freely available fonts that are set
>up with tables so that characters in these positions render as
>specified. People sometimes quote the code2001 project but
>http://home.att.net/~jameskass/code2001.htm
>still says of mathematics:
>
>    In this version, the special letter forms for Mathematics are (still)
>    not completed, and many of them are wrong, rough, or inappropriate.

Is this a problem of how the fonts are encoded, or that the glyphs
are not freely available. If it's the later, then that doesn't have
anything to do with the plane 1 vs. pua issue. If the former, it
should not be too difficult to take a font and recode it, if
it is a free font.



>   Second, I just had a look at
>   http://www.w3.org/TR/2003/WD-MathML2-20030411/isoamsa.html.
>   Some of the glyphs come with boxes around them, and for some
>   others, there is just a gray box. I'm not sure there is
>   a need anymore to distinguish different classes of characters.
>
>
>The grey box is "none.png" which is a link the stylesheet creates
>if a better character image isn't supplied. I hope to generate some
>more images now the actual code assignments are stable, once we've
>finished handling last call comments to the text of the spec.
>Similarly the images with boxes are older images from the mathml-1 spec
>that just have a border within the image. Hopefully we'll be able to
>regenerate those as well sometime, but they are lower priority than the
>images that are missing.

Just in case this is not already listed as a last call comment,
I think it would be very important to fix this before publishing
the second edition. If you have problems with getting appropriate
glyph images, I suggest you talk to somebody from the Unicode
Consortium.

Proposed resolution: Spec fixed

Actually I'm not sure why this issue isn't closed, you requested that we
don't remap the plane 1 characters to the PUA in the xhtml+mathml DTD,
and that we don't describe this mapping in appendix A. We did both these
things (the revised xhtml+mathml dtd is already public) so I assume that
you accept the resolution of that comment.
You made some further remarks about the older sample character images
which had borders. I have since removed all the borders, and there are
now images for all characters that are used in the mathml DTD, so
again I hope that you will be happy to accept this outcome.

Issue 11-27. Status: closed

From I18N WG

B Content Markup Validation Grammar

 >>>>
[4]     Char     ::=      Space | [#x21 - #xFFFD] | [#x00010000 - 
#x7FFFFFFFF]  /* valid XML chars */
 >>>>

This production is clearly wrong, and needs to be fixed.
    

Proposed resolution: Spec fixed

Spec fixed

Issue 11-28. Status: closed

From I18N WG

XML Schema, at http://www.w3.org/Math/XMLSchema/mathml2/mathml2.xsd
(several files):


<?xml version="1.0" encoding="UTF-8"?>
...
<xs:annotation>
   <xs:documentation>
   This is an XML Schema for MathML.
   Author: St&#233;phane Dalmas, INRIA.
   </xs:documentation>
</xs:annotation>

"&#233; : If this is UTF-8, then please use UTF-8.
    

Proposed resolution: No change

Note that the schema is not distributed as part of the REC track process
in TR, so this isn't handled as a last call comment on the mathml
specification document. Basically we have decided to leave this as it is
for now, Stephane is surely free to write his own name any way he wants,
and this way is perfectly valid XML. Many people find it more convenient
to use character references rather than character data, which is why XML
has character references. But as I say this is a non-issue as far as the
last call process is concerned. The schema is distributed from the Math
WG pages to its own release schedule.

Issue 12-1. Status: closed

From Andreas Strotmann

I stand corrected then, Robert.

However, it does say "should", not "must", so any content element is OK, 
sort of, except reln, which is explicitly depracated. You may have to 
fix the validation grammar then (though it should issue a warning, I 
suppose).

Still, the original poster appears to have hit upon a serious problem 
here.  I can't think of a single case where insisting on a specific type 
of argument would be OK in all cases.  In this particular case, just 
replace the body, variable x, with a logical constant such as true or 
false, and you have a perfectly sensible mathematical statement that 
should be representable in a straight-forward way without inserting an 
identity function into it somehow.

[...]

>>The misunderstanding may be about <forall/> being required to be used 
>>within the context of an apply element.  That refers to the apply 
>>element within which the forall element is embedded, however, and 
>>therefore there is no problem if there is no apply element as a sibling 
>>of the forall element.
>>    
>>
>
>That may be the sensible interpretation, but it isn't how the spec is
>written.  From 4.3.17:
>
>  "The forall element represents the universal quantifier of logic. It
>  must be used in conjunction with one or more bound variables, an
>  optional condition element, and an assertion, which should take the
>  form of an apply element. In MathML 1.0, the reln element was also
>  permitted here: this usage is now deprecated."
>
>And from the validation grammer, C.2.3.18:
>
>  "Signature 
>
>    (bvar*,condition?,apply) -> boolean 
>    (bvar*,condition?,(reln)) -> boolean "
>
>--Robert
    

Note that the signatures in Appendix C are  not "exhaustive" so
that in particular, there probably should have been an example with 
something
other than an apply.

Csymbols should be  allowed as arguments any place an apply might be used
as an argument ( since you can always fake it using applying the 
identity function
to the csymbol ... )

A slight change in the wording of this paragraph so that it becomes 
illustrative
rather than prescriptive plus the inclusion of one or more extra example 
signatures
would probably resolve the issue (for this specific case ...) 

As Andreas has pointed out, the general issue of being too prescriptive
has been come up before.

Proposed resolution: Spec fix

The validation grammar has been fixed to make the treatment of these
and other operators more regular and to allow more general
arguments. As a result, some uses that were arbitrarily restricted
before either
in the wording or the grammar now are allowed.

In fixing the grammar, we have taken into account that this was a
general problem and the arity requirements have been relaxed.  The
primary change in the grammar has been that it now treats most of
the operators that could sensibly be n-ary as n-ary and also allows
use of domain of application in all its various forms.

The old usage is of course still valid.

Issue 12-2. Status: closed

From Andreas Strotmann

This reminds me of a problem that I posted a long, long time ago, about 
having interval both as a constructor and as a qualifier element. 
 That's a dangerous syntactic ambiguity: is an apply with an integral 
operator and an interval element a) an operator on functions which 
returns the integral of an argument function over that interval, or b) 
the indefinite integral of an interval-valued function?

[...]

So much for the problem.  As a solution, I would recommend deprecating 
the use of interval as a qualifier in favor of  a domainofapplication 
qualifier with an interval constructor child. (Ah yes, I really do 
recommend making domainofapplication a qualifier, not a constructor.)

<apply>
  </int>
  <bvar> ... </bvar>
  <domainofapplication> <interval> ... </interval> </domainofapplication>
  <apply>... </apply>
</apply>
    

Proposed resolution: spec fix

Interval may still be a qualifier, but the possible ambiguity has been
addressed.  In the ordinary course of events, when used in an apply
where a qualifier is expected then it is a qualifier.  If anything
occurs (such as multiple occurrences of an interval) to put this
interpretation in doubt then they must be interreted as an ordinary
operands.

Issue 12-3. Status: closed

From Andreas Strotmann

I just realized that there is yet another problem with this definition:

>>
>>  "The forall element represents the universal quantifier of logic. It
>>  must be used in conjunction with one or more bound variables, an
>>  optional condition element, and an assertion, which should take the
>>  form of an apply element. In MathML 1.0, the reln element was also
>>  permitted here: this usage is now deprecated."
>>
>> And from the validation grammer, C.2.3.18:
>>
>>  "Signature
>>    (bvar*,condition?,apply) -> boolean    (bvar*,condition?,(reln)) 
>> -> boolean "
>
Like the integration operator, which is used in examples in the MathML 
document either as binding its own variables or as operating on 
functions, and which can therefore be used both with and without bvar 
qualifiers, it is (perhaps surprisingly) quite common to do something 
similar with the standard quantifiers, especially in linguistics/formal 
semantics texts.  It is quite common there to use

<apply>
  <forall/>
  <lambda> <bvar> <ci>x</ci> </bvar>
    ...
  </lambda>
</apply>

that is to interpret forall as an operator acting on predicates.  This 
usage would be forbidden by the current definition.

I believe I suggested years ago that the equivalence of variable binding 
operators and their interpretation as operators acting on functions (or 
in this case, predicates) be respected by MathML, and was told that that 
was a good idea and MathML would do so, as indeed it has in the case of 
<int/>.

Please use int as a precedent and state in very general terms that an 
apply with bvar qualifiers can always be re-phrased as an apply with a 
single lambda term argument in this manner, and that therefore there are 
no operators in the language that require bvar qualifiers.

Proposed resolution: Spec fix

[JSD]  fixed as per the general changes for domainofapp

Issue 13-1. Status: closed

From Andreas Strotmann

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'.
    

Proposed resolution: spec fix

fixed in spec

Issue 13-2. Status: closed

From Andreas Strotmann

2.4.5, third paragraph.

 > The |id| is also used in this context.

should read

 > The id attribute is also used in this context.
    

Proposed resolution: spec fix

fixed in spec

Issue 13-3. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: no change

We left the list as is since this is a second revision to the
spec and we wanted to minimize changes against the previous
versions.

Issue 13-4. Status: closed

From Andreas Strotmann

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'?
    

Proposed resolution: no change

We
left this as is. We wanted to minimize change and the token list as it
stands is not exhaustive anyway.  A more precise statement should try
to be exhaustive and would not be appropriate in the
introduction. About 'marked up': Left as is, to minimize change.

Issue 13-5. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: no change

We
have left this discussion in section 4.2.1.8 and changed the wording
there to be more comprehensive

Issue 13-6. Status: closed

From Andreas Strotmann

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)
    

Proposed resolution: spec fixed

This phrasing has been clarified.

Issue 13-7. Status: closed

From Andreas Strotmann

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)
    

Proposed resolution: spec fixed

Fixed.

Issue 13-8. Status: closed

From Andreas Strotmann

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).
    

Proposed resolution: spec fixed

Fixed. We found we were able to fit in this suggestion
without breaking any of the old uses.

Issue 13-9. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fixed

Fixed.

Issue 13-10. Status: closed

From Andreas Strotmann

4.2.2.3

mention again that declare is only allowed at the top-level.
    

Proposed resolution: spec fixed

Fixed.

Issue 13-11. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fixed

The
intended interpretation of this example and a lambda based alternative
has been provided. Example of minus being both binary and unary is
included in the description.

Issue 13-12. Status: closed

From Andreas Strotmann

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).
    

Proposed resolution: spec fix

Deleted.
This was easily misconstrued to read that declare was allowd in the
body of applies.

Issue 13-13. Status: closed

From Andreas Strotmann

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.

Proposed resolution: spec fix

Fixed.

Issue 13-14. Status: closed

From Andreas Strotmann

As mentioned earlier, I propose to deprecate the use of interval as a 
qualifier. This would cause several changes in this section.

The interval was retained as it is a natural way to represent
intervals along a curve.  It makes it easier to come up with
appropriate presentations instead of having to decipher a complicated
domainofapplication expression.

However, wording has been added to clarify that it is really an
abbreviation for a suitable "domainofapplication".

This is a good thing to do as such, but doesn't address the real issue
wrt. interval qualifiers vs. constructors that I had raised in earlier
messages and that I was referring to here.

That issue is with *ambiguity*, which you mentioned in your response
to me as the second main purpose of this second edition errors. There
are cases imaginable (though admittedly rare in practice) where it may
not be possible to disambiguate between a reading of an
<interval>..</interval> as a constructor of an interval on the one
hand and the reading of the same expression as a qualifier of the
surrounding apply on the other. I think I posted examples earlier, and
showed that these different readings lead to radically different
semantics, which makes this a serious problem in my book.

One possible way to avoid this ambiguity is to deprecate one of these
two uses, and since the interval qualifier can easily be replaced,
that's the one I recommended for depracation. Also, this was my *only*
reason for this recommendation - I was quite aware of the usefulness
of these different ways of representing the domainofapplication
concept.

The problem with the solution you describe is that, though it nicely
ties the different ways of specifying domains of application together,
it in no way addresses the ambiguity problem.

I admit, however, that the easy way out that I suggested
(i.e. deprecation) is perhaps a bit too radical for a second edition,
besides having the disadvantage of breaking old code and examples. An
alternative solution could take the form of specifying an algorithm
that is guaranteed to determine, from context, whether an interval
element is a qualifier or a constructor. This algorithm would probably
require some reasonable restrictions on the use of interval as a
qualifier; here is a sample restriction that would make such a
decision algorithm easy to specify:

  "as a *qualifier*, an interval element *must* be accompanied by a
bvar sibling,
   which it must *precede*." (This would change the standard order of
qualifiers, I suspect, but would guarantee easy disambiguation. Any
interval appearing in this configuration is already guaranteed to be a
qualifier by the current MathML spec, since qualifiers must precede
all regular arguments, and an interval head element must be a
constructor).

Perhaps the problem is best captured by the example

<apply><plus/>
<interval><ci>0</ci><ci>1</ci></interval>
<interval><ci>1</ci><ci>2</ci></interval>
</apply>

With plus allowed to have a domainofapp, (as happens with a  uniform
treatment of n-ary perators ... )
 this becomes ambiguous, and I can imagine wanting to add together
intervals.  The author
could still disambiguate this by specifying a definitionURL for plus,
-
forcing their own
specific interpretation on  how the interval qualifier is handled, but
perhaps something more is needed.

We'll get back to you on this.

Proposed resolution: clarification

We have elected to keep interval as both a qualifier and a
regular object, but have described how to resolve ambiguitie that may
arise.

Issue 13-15. Status: closed

From Andreas Strotmann

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.

Proposed resolution:

Deleted the sentence.

Issue 13-16. Status: closed

From Andreas Strotmann

diff:

The example uses fn, which is deprecated.

We have introduced a "function" type value for use with the
type attribute and used it in place of "fn".

Good.

Is it possible to use both a "function" and a "real" type value
simultaneously to denote a real function?

The answer is yes. There is nothing preventing you
from specifying a type as type="real function", or for
that matter  type="function(real)".  The attribute value
is only restricted to be a string.

This also touches on a point raised by Clare So regarding
the trade-offs between an open list of types versus a close list

http://lists.w3.org/Archives/Public/www-math/2003May/0027.html

Concensus on the committe  seems to be that
the presence of a type, especially if an application
does not recognize it allows the applicatioon to
react appropriately and that the need for such
extensions out weighs the need for a fixed list.

As you are well aware, the whole issue of types is
much more complicated, and we need to build on the
work that is being done in this area.
A note is being prepared that addresses the issue
of how to associate general types with MathML objects.
Once the spec revisions settle down we will get back
to that.

Proposed resolution: spec change

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.

Issue 13-17. Status: closed

From Andreas Strotmann

partialdiff:

Why is the optional degree qualifier available for partialdiff but not 
diff? That seems inconsistent to me.

The diff operator is explicitly univariate and the degree can
always be inferred from the degree of the bound variable.

The partialdiff's degree qualifier enables one to more
easily write the total degree  in    d^(m+n)/(dx^m dy^n)
or   d^3/(dx dy dz)  without requiring the implementation of
software to introduce the algebraic
arithmetic necessary to compute the total degree.

Not for display it can't: d/dx  d/dy  d/dz f    is usually written
d^3 f/dx dy dz, so that you have exactly the same problem as for
partialdiff.

No matter what we do,  when univariate an algorithm for deriving a
presentation must currently unwrap three nested apps of diff while if
it becomes multivariate this may introduce confusion with partialdiff.
Well have to  reflect on this and get back to you.

Proposed resolution: no change

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.

Issue 13-18. Status: closed

From Andreas Strotmann

forall, exists:

I have argued elsewhere that it is not necessary to require at least one 
bvar qualifier to go with these.
    

Proposed resolution: spec change

This requirement has been relaxed as you suggest
so that by analogy with int() or sum(), you can now write

	Forall( domainofapplication(C) , f )

where f is a function evaluated at points of the domain and
plays the role of an assertion.

The domainofapplication qualifier is now treated uniformly
across all operators that support domainofapplication
and its shortcut notations. Thus in addition to the above
we can also write:

	Forall( bvar(x) , domainofapplication(
		set(bvar(X),condition(X>=1 andX<=5)) , f(x) )

which can be shortened to (depending on the circumstances
and preferences)

	Forall( bvar(x)  , condition( x >=1 and x <= 5 ) , f(x) )
	Forall( interval(1,5) , f )
	Forall( bvar(x) , lowlimit(1), uplimit(5) , f(x) )

Each shortened forms maps more naturally to
particular presentations.  Depending on the operator,
one particular shortened form may better reflect common
usage than another (e.g. int and lowlimit, uplimit),
but by making all the short forms valid  the treatment has
become consistent across the board.

Issue 13-19. Status: closed

From Andreas Strotmann

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.

Proposed resolution: spec fixed

Fixed.

Issue 13-20. Status: closed

From Andreas Strotmann

unary/binary/... : the discussion above applies here too.

Fixed.

Here, I see only one 'fixed' but two suggestions. ??

This clarification has hit in several places, but I'll check and get
back to you.
The basic notion has been incorporated.

Proposed resolution: spec fixed

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.

Issue 13-21. Status: closed

From Andreas Strotmann

4.2.5.

mention that conditions can be used with arbitrary "heads" of their 
apply, just like bvars.
    

Proposed resolution: spec fixed

Fixed.

Issue 13-22. Status: closed

From Andreas Strotmann

4.2.5.1, second example

use MathML constant symbols instead of OpenMath csymbols for the sets N 
and P.
    

Proposed resolution: no change

Reasonable suggestion, but we have left the example as is
partly to retain its value showing external references.

Issue 13-23. Status: closed

From Andreas Strotmann

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.
    

The type attribute could be used to specify this, or alternatively
a definitionURL, so we have left this as is.

So, did you add this kind of type attribute (along with the new one
for 'function' you mentioned earlier)?

Both the type attribute and definitionURL's can have any string as a
value so
the hooks are there, but specific attribute values with this meaning
are not spelled
out.   To properly introduce this we would need to introduce some
classes of
operators, and some notation to refer to them which was a fairly big change
so we elected to leave it as is.

(personal remark)  I suspect the best way to proceed on something like
this is to
use the existing hooks to model it, and then when this stabalizes move it in
in some future revision.

Proposed resolution: no change

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.

Issue 13-24. Status: closed

From Andreas Strotmann

4.4.2.1.1 last paragraph

Mention user-defined symbols in the context of qualifiers, too
    

Proposed resolution: spec fixed

fixed.  (also ci's "declared")

Issue 13-25. Status: closed

From Andreas Strotmann

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:

Proposed resolution: spec fixed

Agreed and fixed.

Issue 13-26. Status: closed

From Andreas Strotmann

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).
    

Proposed resolution: spec fixed

fixed.

Issue 13-27. Status: closed

From Andreas Strotmann

4.4.2.7.1.  

mention that reln is deprecated.
    

Proposed resolution: spec fixed

fixed.

Issue 13-28. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fixed

This content model has been relaxed to allow qualifiers
  as in lambda( bvar(x), qualifier , f(x) )

Issue 13-29. Status: closed

From Andreas Strotmann

4.4.2.9.3

shouldn't the default rendering be more like  \lambda x. f  ?
    

Proposed resolution: no change

The notation used for lambda expressions is certainly not
as common, but understandable and so we have left it as is.
If changed, it will be changed systematically throughout the spec.

Issue 13-30. Status: closed

From Andreas Strotmann

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.
    

The definitionURL (together with a domainofapplication)
accommodates this need so we have not changed it.

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>

Proposed resolution: clarification

Indeed,  I made a mistake in the lambda example in this message.
Thanks for catching it.  I (tried to use) used the functional form
deliberately to point
out that there are reasonable interpretations without bvars.

Issue 13-31. Status: closed

From Andreas Strotmann

4.4.2.15

mention that domainofapplication is a qualifier element
    

Proposed resolution: spec fix

Fixed.

Issue 13-32. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fix

We have relaxed these constraints so that the degenerate
cases may now occur.

Issue 13-33. Status: closed

From Andreas Strotmann

4.4.3.5

add a unary minus example
    

Proposed resolution: no change

left as is ... It's absence has not caused any problems.

Issue 13-34. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution:

Fixed

Issue 13-35. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fix

Fixed

Issue 13-36. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fix

Changed the example to use interval without a bound variable.

Issue 13-37. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: no change

This was as far as we could go without feedback
on different approaches to multivariate calculus.
The extension mechanisms allow this experimentation
to take place.

Issue 13-38. Status: closed

From Andreas Strotmann

4.4.5.6.1

mention that bvar can be used with user-defined or even compound "heads".
    

Proposed resolution: spec fixed

Reworded

Issue 13-39. Status: closed

From Andreas Strotmann

4..4.5.6.3

the default rendering of the first example should be $\frac{d^2 x^4}{dx^2}$
    

Proposed resolution: spec fixed

Fixed

Issue 13-40. Status: closed

From Andreas Strotmann

4.4.5.8/9/10

add default renderings with \nabla, as in the case of the laplacian
    

Proposed resolution: spec fix

Done.

The existing images kept but supplemented with three new images
so the default rendering will be shown with two images separated by "or"
(This is the same format as currently used for mean in 4.4.9.1.3)

grad a   or  \nabla a
curl a   or  \nabla \times a
div a    or  \nabla \cdot a

Issue 13-41. Status: closed

From Andreas Strotmann

4.4.6.9/10

the default renderings in 4.4.6.9 and .10 need to be swapped.
    

Proposed resolution: change

Swapped, thanks.

Issue 13-42. Status: closed

From Andreas Strotmann

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 ;-)
    

Proposed resolution: no change

The condition now works as suggested here.

Issue 13-43. Status: closed

From Andreas Strotmann

4.4.7.1, .2

we can also use domainofapplication here.  Mention also that a function 
argument without a bvar qualifier is possible.
    

Proposed resolution: spec fix

Fixed

Issue 13-44. Status: closed

From Andreas Strotmann

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

Proposed resolution:

This was deemed to be a stylistic difference and left as is.  :-)

Issue 14-1. Status: closed

From Andreas Strotmann

C.1 second paragraph, second sentence

strike 'if'

Proposed resolution: Spec fix

Fixed

Issue 14-2. Status: closed

From Andreas Strotmann

C.1.1 first paragraph, first sentence

'used' -> 'use'
    

Proposed resolution: Spec fix

Issue 14-3. Status: closed

From Andreas Strotmann

C.1.1 third paragraph

first word "This" -> 'The';  insert comma after 'standardization effort'
    

Proposed resolution: Spec fix

Issue 14-4. Status: closed

From Andreas Strotmann

C.1.2

- function (operator), second paragraph, third sentence

insert 'as' after 'used'
    

Proposed resolution: Spec fix

Fixed.

Issue 14-5. Status: closed

From Andreas Strotmann

- signature, second paragraph, first sentence

 'to type of mathematical object that is constructed.' -> 'to the type 
of the mathematical object it constructs' (for example)

Proposed resolution: Spec fix

Fixed as: 'with the type of mathematical object'

Issue 14-6. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: clarification

Fixed.

Issue 14-7. Status: closed

From Andreas Strotmann

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
    

Proposed resolution: spec fixed

    [JSD] The wording here and in chapter 4 has been reviewed to make clear
    that all uses of the "fn" constructor are deprecated.

Issue 14-8. Status: closed

From Andreas Strotmann

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)
    

Proposed resolution: clarification

     [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.

Issue 14-9. Status: closed

From Andreas Strotmann

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
    

Proposed resolution: spec fixed

    [JSD] type=function always was allowed, but now it is one of the
    officially  listed types.

Issue 14-10. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: spec fixed

    [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) ) , ... )

Issue 14-11. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: clarification

    [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.

Issue 14-12. Status: closed

From Andreas Strotmann

C.2.2.10

use a small circle Unicode character instead of @ in the description
    

Proposed resolution: spec fix

Fixed

Issue 14-13. Status: closed

From Andreas Strotmann

C.2.2.13

The property should use Exists as in   Forall(y, Exists(x,y=f(x)), y in 
codomain(x))
    

Proposed resolution: Spec fix

Fixed

Issue 14-14. Status: closed

From Andreas Strotmann

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))
    

Proposed resolution: Spec fix

    [JSD] fixed.     However, we have not added any special
    properties.for definitory equivalence

Issue 14-15. Status: closed

From Andreas Strotmann

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

Proposed resolution: spec fix

    [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.

Issue 14-16. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: fixed

    [JSD]  signature and consistency with chapter 4 [JSD]  Fixed.

Issue 14-17. Status: closed

From Andreas Strotmann

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.
    

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.

This resolution is inconsistent with others, where an attempt has been
made to reduce the number of restrictions in the signatures as much as
possible, whenever that appeared reasonable.

For all intents and purposes, relations simply *are* boolean
functions, and indeed are more likely than other functions to be
defined piecewise, e.g.

  relation   strictly_positive(x) := true if x>0, false otherwise.

<diatribe>
This is clearly K-14, and there is absolutely no reason to believe
that this is 'non-standard' in any way, shape, or form.

This is yet another excellent example why it is extremely dangerous to
try and enforce arbitrary restrictions on allowable arguments for
mathematical formulas. I strongly recommend a policy of 'in dubio pro
reo' -- i.e. when in doubt, it's allowed.
</diatribe>

Proposed resolution: Spec fix

Issue 14-18. Status: closed

From Andreas Strotmann

C.2.3.1 first paragraph

'positive' -> 'non-negative' (since a may be 0)
    

Proposed resolution: Spec fixed

Spec fixed

Issue 14-19. Status: closed

From Andreas Strotmann

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.
    

    [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.

Actually, I learned that

      max(true,false)=true

in highschool, and thus, for example, even for K-14ers,
     max(domofapp(truthvalues),<not/>) = <true/>

At first glance my above diatribe thus applies here, too.

Still, I can't come up with a large set of K-14 examples where this
would really make sense, except in this one single, admittedly
contrived, example.

Proposed resolution: spec fixed

 We still we feel  that the notion of  a "total order" on the booleans
is just enough outside the usual expectations for max/min that we
would like to see such uses flagged  with the use of a definitionURL
pointing to an explanation of the convention being followed.

Issue 14-20. Status: closed

From Andreas Strotmann

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].
    

Proposed resolution: Spec fix

[JSD]  fixed as per the general changes for domainofapp

Issue 14-21. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: Spec fix

    [JSD]  fixed as per the general changes for domainofapp

Issue 14-22. Status: closed

From Andreas Strotmann

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).
    

Proposed resolution: Spec fix

Fixed

Issue 14-23. Status: closed

From Andreas Strotmann

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.)
    

Proposed resolution: fixed

Fixed.

Issue 14-24. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: fixed

Fixed.

Issue 14-25. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: no change

    [JSD]  This was left as binary as it was felt that there were too
    many choices for what n-ary might mean.

Issue 14-26. Status: closed

From Andreas Strotmann

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)?
    

Proposed resolution: Spec fixed

Fixed.

Issue 14-27. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: Spec fixed

    [JSD]  fixed as per the general changes for domainofapp.  The
    "interval" proposal has been discussed elsewhere.

Issue 14-28. Status: closed

From Andreas Strotmann

C.2.5.2

I remarked in my previous posting that this should perhaps be defined 
more like partialdiff.


    

Proposed resolution: no change

    [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.

Issue 14-29. Status: closed

From Andreas Strotmann

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.
    

Proposed resolution: Spec fix

Fixed.

Issue 17-1. Status: closed

From Simon Pepping

In section 3.3.4.2 color is listed as an attribute of mstyle. Because it is
an attribute of all token elements, it need not be listed here.
    

Proposed resolution: spec fix

Removed.

Issue 17-2. Status: closed

From Simon Pepping

In the DTD mstyle can have the attribute %att-accentunder; (but not
%att-accent;). I think it should be removed, since it is not inheritable.
    

> In the DTD mstyle can have the attribute %att-accentunder; (but not
> %att-accent;). I think it should be removed, since it is not inheritable.

In fact the DTD does specify the accent attribute (%att-accent;) is
allowed on mstyle, this is included in %att-opinfo; which is included
into mstyle's attribute list.

att-accentunder does appear explictly in mstyle's attribute list as it
isn't in att-opinfo.

We discussed your comment that these attributes should not be in the
DTD. The current settings are intentional and so we plan to keep
the DTD as it is in this case.

The following explanation comes from Robert Minor, who I hope won't mind
if I plagiarise his text from our internal discussion:

>   You can set anything except required attributes on mstyle.  
>   
>   From the spec:
>    
>     The mstyle element is used to make style changes that affect the
>     rendering of its contents. mstyle can be given any attribute accepted
>     by any MathML presentation element provided that the attribute value
>     is inherited, computed or has a default value; presentation element
>     attributes whose values are required are not accepted by the mstyle
>     element. In addition mstyle can also be given certain special
>     attributes listed below. 
>   
>   If an attribute is not inheritable, setting it on mstyle has the
>   effect of changing the default value for all elements within its
>   scope.  For an inheritable attribute, setting it on the mstyle causes
>   it to be inherited normally by its children.  But either way you can
>   set the attribute just fine.

As this is a last call comment could you confirm on this mailing list
whether or not you are happy with this resolution as we have to document
the outcome of all last call comments, thanks.

Also, as far as I can tell this is the last of your DTD comments in this
round to have been handled. If you think there is a message that I have
missed and you haven't seen a reply please send me a reminder.

Proposed resolution: Spec fixed

Issue 18-1. Status: closed

From Simon Pepping

In a recent discussion with publishing colleagues the following question
came up: What is the meaning of 

<mi mathvariant="bold">&#x1D538;</mi>

Is it at all allowed? If the answer is clear, then maybe the explanation in
the spec should be expanded to include it. Or is it not possible to give a
definite answer in the current version of MathML?
    

My opinion is that it's allowed, but not meaningful, and probably
shouldn't have any effect on rendering.  The relevant paragraphs from
section 3.2.2 of the spec that I base this on is:

   "A issue arises in that the natural interpretations of the mathvariant
   attribute values only make sense for certain characters. For example,
   there is no clear cut rendering for a 'fraktur' alpha, or a 'bold
   italic' Kanji character. In general, the only cases that have a clear
   interpretation are exactly the ones that correspond to SMP Math
   Alphanumeric Symbol characters.

   "Consequently, style sheet authors and application developers are
   encouraged in the strongest possible terms to respect the obvious
   typographical interpretation of the mathvariant attribute when applied
   to characters that have SMP Math Alphanumeric Symbol counterparts. In
   all other cases, it is up to the renderer to determine what effect, if
   any, the mathvariant attribute will have. For example, a renderer
   might sensibly choose to display a token with the contents ∑ (a
   character with no SMP counterpart) in bold face font if it has the
   mathvariant attribute set to 'bold' or to 'bold-fraktur', and to
   display it in a default Roman font if the mathvariant attribute is set
   to 'fraktur'. As this example indicates, authors should refrain from
   using the mathvariant attribute with characters that do not have SMP
   counterparts, since renderings may not be useful or predictable. "

I guess I should have read that section better. Still I am not quite
satisfied.
- The notion of correspondence is not well defined. It suggests something
similar to lc-uc correspondence, but it is not defined.
- Since the SMP Math Alphanumeric Symbol characters only contain latin and
greek alphabetic characters and digits, I keep the feeling that mathvariant
only makes sense with those characters.
- Thinking about this, I feel that the sum example is wrong. <mi
mathvariant="bold">A</a> is a semantically different character from A, <mo
mathvariant="bold">&sum;</a> is only a style variant of this operator, and
that is not what mathvariant is supposed to convey.

Actually, I had a similar case that I wanted to do in TeX recently, but 
couldn't figure out how.  In the Lambek Calculus which I used in my 
dissertation there are left and right slashes that do *not* mean 
division. Their corresponding 'multiplication' has a black bullet 
notation (probably meant originally as a bold multiplication point), and 
therefore using a mathvariant=bold of the slashes would have made 
excellent sense in that notation (indeed, as I said, I actually went and 
tried to do that by wrapping a \mathbf around the slashes, but that 
didn't appear to work, so I just gave up on that idea).  Since the 
meaning of those slashes is different from regular division and 
set-difference, say, the mathvariant solution would have been quite 
appropriate by your standard as it was meant to underscore a deeper 
semantic distinction.

This is just meant to help clarify the situation a bit better, but in no 
way as an attempt to solve the actual question itself, which I gladly 
leave to the experts.

Proposed resolution: spec fixed

I rewrote the text of 3.2.1.1 and 3.2.2 to make this clearer.  It used
to say that when the mathvariant attribute was applied to character
data outside the ranges defined in chapter 6 (the plane 1 alphanumeric
characters) where there is a clear BMP+mathvariant/SMP correspondence,
it was up to the renderer to decide what happens  (so don't do it).  Now
it says that we suggest renderers ignore the mathvariant attribute in
these cases (so don't do it).

Issue 19-1. Status: closed

From Clare So

Section 4.3.2.9 of the MathML reccomendation states that the "type" 
attribute of a <ci> can be "the name of any content element".  In my 
opinion, the fact that arbitrary type is allowed may hinder the 
particular element to be transformed into other document forms, such 
as OpenMath, while preseving the complete semantics of the particular 
<ci>.  In the "mathmltyles" OpenMath CD, there are only a 
finite number of types available to add type information to a 
mathematical object.  What do other people think?
    

So, we are allowed to use attribute values of "integer, rational, real,
float, complex, complex-polar, complex-cartesian, constant" that allows
for identifiers to be typed with a bunch of 'numerical' types. However one
may also want an identifier to be a function, maybe <ci
type="lambda">foo</ci>, or a matrix <ci type="matrix">M</ci>, set, vector,
polynomial etc. I see that in the CD mathmltypes there are symbols for
fn_type, list_type, matrix_type, set_type, vector_type. I guess that the
phrase "the name of any content element" could be thought of as pretty
open-ended seeing as you do have csymbol and semantics in content MathML.
But this is good isn't it?

The whole point (well major point) with OpenMath is extensibility, so if
your problem is problems with converting from MathML to OpenMath, I would
suggest writing your own mathmlmoretypes CDs, and maybe submitting on the
OpenMath submissions page:

http://monet.nag.co.uk/cocoon/openmath/cdfiles/contrib/index.html

Proposed resolution: No change

Please see my response to Andreas (just sent)
in which I discuss the possible values of the
type attribute.  In the end, it boils down to a
strong need for the flexibility of extensions, and
the fact that just the presence of the attribute
tells the applications to be careful.  Thus
we are not planning on changing this feature.

Issue 9-1. Status: closed

From QA WG

Ref:  http://www.w3.org/QA/WG/2003/05/SpecGL-MathML20-review.html

Our (QAWG) apologies that we didn't send these comments before your Last 
Call closed, even though they were ready.  For a variety of reasons 
(travel, vacations, meetings, publications, etc), actually sending them 
slipped between the cracks.

We have taken a look at the Last Call text of MathML 2.0 Second Edition, 
from the perspective of conformance to "QA Framework:  Specification 
Guidelines" (SpecGL, [1], which is *our* Last Call version of that 
specification).

We recognize that the MathML 2.0 spec is a Second Edition, and therefore 
the scope allowable changes is very constrained.

Nevertheless, we offer the review in the hopes that MathML WG finds it 
interesting and/or useful.  In fact, MathML 2.0 Second Edition scored 
pretty well against the SpecGL, as you will see in the review comments.
    

Proposed resolution: spec fixed

This is the back matter from the review you posted at
<http://www.w3.org/QA/WG/2003/05/SpecGL-MathML20-review.html>.


> Generally the specification conforms well to SpecGL. 
> 
> The main weakness is lack of information about the conformace
> implications of extensions to the spec. The possibility of extensions
> is readily acknowledged and in the main case a mechanism is provided
> but it is noted that there are interoperability issues here which are
> not dealt with other than to dissuade an implementer from using the
> extension mechanism where possible. 

We've added a new section "7.2.1.3 MathML 2.0 Extension Mechanisms and
Compliance"  It ennumerates the three extension mechanisms that MathML
2.0 sanctions -- mglyph, namespaced attributes for maction, and
definitionURL in content markup.  

We then describe how abuse and/or future standards activity might lead
to contradiction with the spec, or at least undesirable consequences.

Finally, there is a paragraph cautioning implementor and maintainers
of documents to be aware of the issue, and monitor relevant
conventions and standards activity.

> The spec. does not use strong, prescriptive RFC2119 language and this
> makes it harder to locate assertions (but easier to read...). Specific
> requirements are not tagged (to allow linkage to tests) although there
> is a test suite (which I haven't looked at) 

We dicussed using RFC2119 language, but in the end concluded not to do
it.  The reasoning was that if we limited its use to the section on
compliance in chapter 7 it wouldn't be much use, since there are lots
and lots of assertions throughout the text that should then also be
stated in those terms.  On the other hand, making all those changes
would have a very significant impact on the spec, and we weren't at
all confident we could do it without introducing new and non-obvious
problems. 

> I was a little confused about product classification. There is more
> than one classification scheme for the same set of applicable
> products. Conformance product classes and discretionary implementation
> classes use different terms. 

We added a few sentences in chapter 7 about product categories.

> There is a separate document for "Compliance Guidelines". This
> document appears to duplicate material in the conformance section of
> the specification which raises document maintenance concerns. Also
> both 'compliance' and 'conformance' are used (to mean the same
> thing). 

For the 2nd Edition, our thought was to update this the Guidelines to
serve more as a guide to current activity, e.g. new validation tools,
interoperability tests, etc.  Clearly it should not just regurgitate
the spec, as it currently does.

Also, we changes 'conformance' to 'compliance' in the three places it
appears in the spec.

Issue 15-1. Status: closed

From Andreas Strotmann

  There appears to be some confusion still about how to use the new 
domainofapplication element.  In some places it is clearly marked as a 
qualifier that generalizes the interval qualifier to general sets, but 
in some places (such as in this appendix) it appears to be treated as a 
regular constructor, thus generalizing the interval *constructor*, which 
then brings up what its definition might be.

  It is evident to me that in the minds of those who came up with this 
important addition to MathML, this element was meant to be used 
exclusively as a qualifier (and emphatically not as a constructor) to 
generalize the interval *qualifier* (and in my stated opinion in fact to 
supercede this dangerous dual use of the interval element), and to 
factor out the use of the condition qualifier that allows it to contain 
a set, not just a predicate.

  In the comments that I have been submitting during the past week or 
so, I have therefore assumed that the intention implicit in the choice 
of qualifiers available for general use is as follows:

     bvar - there may be zero(!) or more of these anywhere; they denote
            bound variables in a particular order.

     uplimit, lowlimit, interval, and domainofapplication - these all
            represent sets that restrict the domain of a variable. Thus,
            only the limits (one or both) *or* interval *or*
            domainofapplication may appear in a sensible apply.

     condition - this one is meant to represent a predicate over the
            bound variables of the surrounding element which acts as a
            filter defining the set of combinations of bvar values
            that the operator ranges over.

  Since domainofapplication is new, condition, interval, and the two 
limits covered its use in earlier versions, which leads to a need to 
deprecate the 'double entendre' usage of these older elements that are 
more clearly represented by domainofapplication.  I therefore recommend 
deprecating the following in order to clean up the spec:

      - the use of a condition qualifier that contains the representation
        of a set rather than a predicate -- markup that does this should
        simply replace the condition with the domainofapplication
        qualifier.

      - the interval qualifier (but not the constructor) -- markup that
        uses the interval qualifier should replace it with a
        domainofapplication qualifier that contains an interval
        constructor element with the same content as the original
        interval qualifier instead.

        (Incidentally, this deprecation also makes it easier again to
        understand how an interval *constructor* would need to be
        allowed to contain a single child element, a condition, because
        doing the same thing with an interval *qualifier* seemed rather
        spurious because condition should be used instead.)

With these changes in place, we have a clean separation between the uses 
of the condition and the domainofapplication qualifiers, as follows:

   -  the condition contains a predicate over all the bvars, and may in
      principle be used with an empty set of bvars (in which case it
      becomes a predicate over the free variables).  The predicate is
      in effect the characteristic predicate for a domainofapplication.

   -  the domainofapplication qualifier, by contrast, contains a set.
      In the current definition, there are two cases that need to be
      distinguished:

      a) the signature   op: (bvar,dom-of-app,any) -> any
      b) the signature   op: (dom-of-app,function) -> any

      Of these, a) means the same as

         op(bvar, condition(bvar \in dom-of-app), arg)

      while b) is equivalent to

         op(newvars, dom-of-app, apply(function, newvars))

      Note that in the latter case, the domain of application may
      actually be a cartesian product in order to assign ranges to
      several arguments of the argument function simultaneously.

      This is currently not true in a), but it could be specified
      in the MathML spec that domainofapplication should contain a
      matching-arity cartesian product in the case of multiple
      bvars with one domainofapplication (although the fact that it
      should contain a cartesian product semantically does not mean
      that it would necessarily contain one syntactically -- but if
      it does, its meaning is clear).

      Note also that a) means the same as

        op(dom-of-app,lambda(bvar,arg))

      while  a signature of  op(bvars, condition, arg) is equivalent to

        op(
          dom-of-app(set(bvars,condition,cartesianproduct(bvars)),
          lambda(bvars,arg)
         )

      and a signature like   op(bvars,arg)   means the same as

         op(lambda(bvars,arg))

For the signatures in appendix C (and the corresponding text in the main 
body), all of this translates to a few general rules:

  - lowlimit, uplimit, (deprecated interval), and domainofapplication
    belong in one and the same group of qualifiers, the most general
    of which is domainofapplication.  They are characterized by not
    specifying the names of the variables that they constrain.

  - the second group of qualifiers is the condition qualifier in its
    reduced definition that requires a predicate argument and disallows
    a set argument.  It is characterized by specifically naming the
    variables it constrains.

  - thus, only one of these groups of qualifiers may be used in an
    element, but not both.

  - in cases where operators usually take bvar qualifiers, as in
    int, diff, product, sum, exists, forall, lack of bvars on first
    sight would automatically mean that the single argument must be a
    function, as in apply(int,f) and in apply(diff,f).
    (Incidentally, this rule does not apply to the lambda constructor
    since it does not have an operator.)

    But in the case of n-ary constructors, this is problematic (this
    includes the set and matrix constructors and the min and max
    operators, all of which have versions without any qualifiers
    with an n-ary regular function interpretation, and a version with
    qualifiers interpreted like int and sum or lambda.)

    The problem is that in the current MathML spec, operators like min
    and max (and there are plenty of those) are implicitly 'lifted' to
    their 'big' version (like \wedge -> \bigwedge , i.e. or -> exists
    in a well known notation, or max -> sup):

      'small' signature (A*) -> B

       'big' signature  (function) -> B
                        (domainofapplication, function) -> B
                        (bvar,A) -> B
                        (bvar,domainofapplication,A) -> B
                        (bvar,condition,A) -> B

    In the future, a general-purpose piece of markup for this lifting
    could be useful, so that one could say, for example

        apply(big(max),my_real_fn)

    instead of

        apply(max,my_real_fn)

    which clearly doesn't do the same thing.

    Fortunately, by supplying an empty domainofapplication, this
    semantic lifting can be implemented in MathML in a systematic way
    without introducing the 'big' operator:

        apply(or,domainofapplication(),my_predicate_fn)

     can be defined consistently in MathML to have the required meaning.
     In other words, we can reconcile the 'big' and 'small' signatures
     into a single one by providing the following combined signature:

       'combi' signature  (A*) -> B
                          (domainofapplication,function) -> B
                          (bvar,A) -> B
                          (bvar,domainofapplication,A) -> B
                          (bvar,condition,A) -> B

       Replacing the 'function' with its signature, (A -> B), we get

       'combi' signature  (A*) -> B
                          (domainofapplication,(A->B)) -> B
                          (bvar,A) -> B
                          (bvar,domainofapplication,A) -> B
                          (bvar,condition,A) -> B

      which is unfortunately a bit different from the

          'big' signature ((A->B)) -> B
                          (domainofapplication,(A->B)) -> B
                          (bvar,A) -> B
                          (bvar,domainofapplication,A) -> B
                          (bvar,condition,A) -> B

       From the perspective of automatic, semantically correct processing
       of MathML-Content trees, the crucial question is how to reliably
       distinguish these two cases when all you have is a user-defined
       symbol as an operator (say).  Which of these classes does it
       belong to?  How do you interpret  op(a)  compared with
       op(bvar(x),b)  safely when you cannot know the signature?

       The practical solution is to always assume the 'combi' signature.
       This means that apply(product,a) is interpreted the same as
       apply(plus,a), and that  apply(plus,bvar(x),f)  is interpreted the
       same as apply(product,bvar(x),f), etc.

       This means that the indefinite integration and differentiation
       operators are the only ones that violate this pattern; user-
       defined operators of this sort should always be used with a
       possibly empty domainofapplication qualifier when they want to
       express application to a function (as in 'prime'):  the completely
       qualifier-free use of my_diff_op as in apply(my_diff_op,f) does
       *not* encode  f^\myprime.  Instead, I would have to use
       apply(my_diff_op,domainofapplication(),f) to get the desired
       meaning, unless one is certain that one never would want to
       use it with a bvar qualifier.  (Note that it is not necessary
       to change the signatures of the existing MathML operators, because
       for these, the signatures do exist.)

       This also means that the quantifiers, and the product and sum
       operators *do* have a reasonable meaning when used without any
       qualifiers, and can be assigned the appropriate signature copied
       from the appropriate logical connectives or from times and plus,
       resp.

       Conversely, it means that all n-ary operators have a reasonable
       meaning when used with these qualifiers, and their signatures
       in appendix C should reflect that fact.

       Last not least, it means that apply can be given a general
       signature, too:

         apply:   ((any*->any), any*)                       -> any
                  (((any->any)->any),dom-of-app,(any->any)) -> any
                  (((any->any)->any),bvar,any)              -> any
                  (((any->any)->any),bvar,dom-of-app,any)   -> any
                  (((any->any)->any),bvar,condition,any)    -> any

        where

          dom-of-app:: domainofapplication|uplimit|lowlimit
                          |lowlimit,uplimit

        (leaving out the questionable interval qualifier).

        Still, it might be useful to provide a type attribute
        in MathML to signal that a csymbol is meant to follow the
        pattern of the int and diff operators rather that of the
        max and min operators, just to be on the safe side.
    

It seems to me that any decisions made on the semantics of these elements
will neccessarily have impactions on the corresponding OpenMath symbols,
in content dictionary fns1.
I just had a look at the domainofapplication symbol, which is defined in
the following way:

"The domainofapplication element denotes the domain over which a given
function is being
applied. It is intended in MathML to be a more general alternative to
specification of this
domain using such quantifier elements as bvar, lowlimit or condition."

This is a bug in OpenMath,

1) it is not a 'domainofapplication element' (in OpenMath)
2) The content dictionaries should say what the OpenMath symbols
are intended to represent not the MathML ones!

I guess this was just cut and pasted from the MathML spec.(?)
As far as Andreass discussion gos, one would hope that the OpenMath
interpretation could be fixed (made constant) by the sts file, I had a
look at this, and think that it is rather flawed also:

domainofapplication

<OMOBJ>
 <OMA>
   <OMS name="mapsto" cd="sts"/>
    <OMA>
     <OMS name="mapsto" cd="sts"/>
     <OMV name="Set"/>
     <OMV name="Set"/>
    </OMA>
    <OMV name="Set"/>
 </OMA>
</OMOBJ>

( ( Set >> Set ) >> Set )

personally I would have preferred something along the lines of:

<OMOBJ>
 <OMA>
   <OMS name="mapsto" cd="sts"/>
   <OMA>
     <OMS name="mapsto" cd="sts"/>
     <OMA><OMS name="nary" cd="sts"/>
       <OMS name="Object" cd="sts"/>
     <OMA>
     <OMS name="Object" cd="sts"/>
   </OMA>
   <OMS name="Object" cd="sts"/>
 </OMA>
</OMOBJ>

In fact looking at the entire fns1.sts, I see that almost all the
signatures have this sort of problem!

it would be good to have these ironed out soon. I shall send David a
correct (by my interpretation) version, maybe someone else can check over
that?

Proposed resolution: Spec fix

[JSD]  fixed as per the general changes for domainofapp

Issue 16-1. Status: closed

From Andreas Strotmann

First a general remark on appendix C:

  -  I don't understand why this chapter uses the type 'algebraic' in
     signatures.  It just seems to be another name for 'anything', which
     is also used in places, but I must report that I for one was
     somewhat confused by the term when I first read this text, because
     I have been used to seeing 'algebraic' expressions to stand for
     things that have to do with polynomials over the complex rationals
     and their roots.
    

Proposed resolution: No change

algebraic was chosen over any to make it
    easier to separate out relations.

Issue 16-2. Status: closed

From Andreas Strotmann

C.2.5.3

  - closing parenthesis missing after 'Leibnitz notation'
    

Proposed resolution: Spec fix

Fixed.

Issue 16-3. Status: closed

From Andreas Strotmann

- what is the total degree used for?  I thought that that is always the
    sum of the degrees, and thus easily available.  Unless there are
    cases where that is not true, I'd suggest to deprecate it.
    

Proposed resolution: no change

total degree was discussed in the review of chapter 4.
It is needed to represent the total degree when more than
numeric arithmetic is involved,
e.g. totaldegree n over degree k , degree n-k.

Issue 16-4. Status: closed

From Andreas Strotmann

C.2.5.4, C.2.5.5

  - classification of lowlimit(or uplimit, resp.) should be qualifier.
    

Proposed resolution: Spec fix

Added the qualifier reference
and described the role of the qualifier more completely.  Mentioned
the use of a vector argument to convey multiple upper limits.  Changed
signature to reflect the grammar.

Issue 16-5. Status: closed

From Andreas Strotmann

- The signature says these can have more than one child?  Why?  What
    is the meaning of these if they do?
    

Proposed resolution: Spec fix

The signatures of uplimit and
 lowlimit have been fixed to agree with the grammar (one child).  The
 description was modified to mention that a vector could be used to
 place upper (lower) bounds on more than one bound variable.  We have
 left the examples as is

Issue 16-6. Status: closed

From Andreas Strotmann

- more examples are available with the sum and product operators.
    

Proposed resolution: No Change

Don't add any more examples

Issue 16-7. Status: closed

From Andreas Strotmann

C.2.5.6

  - classification of bvar should be qualifier
    

Proposed resolution: No change

bvar is classified separately from qualifiers, but used
in conjunctionwith them.

Issue 16-8. Status: closed

From Andreas Strotmann

- mention that bvar is productive, i.e. may be used with user-symbol
    operators, for example.
    

Proposed resolution: Spec fix

reworded description of bvar. It is now described a s special
qualifier. Note that in the grammar, qualifiers and bvars are
	handled separately.

Issue 16-9. Status: closed

From Andreas Strotmann

C.2.5.6
  - mention that degree is a qualifier  (it is, isn't it?)
    

Proposed resolution: Spec fix

Fixed.

Issue 16-10. Status: closed

From Andreas Strotmann

C.2.5.9

  - empty second example
    

Proposed resolution: Spec fix

Was removed mistakenly. Restored

Issue 16-11. Status: closed

From Andreas Strotmann

C.2.5.10

  - first paragraph, first sentence:  'both a coordinates *vector* ...'
    

Proposed resolution: Spec fix

Fixed

Issue 16-12. Status: closed

From Andreas Strotmann

C.2.5.11

  - second example

    wrap this example in a <math> element to illustrate that, a),
    XML always comes in single elements, and more importantly b),
    that declare is restricted to top level.
    

Proposed resolution: No change

We need to either wrap a math around every example,
or none of them -- not just some of them.
We have elected to not make this change.

Issue 16-13. Status: closed

From Andreas Strotmann

C.2.6.1, C.2.6.2

  - second example

    this is not licensed by the signature, which requires a body.
    

Proposed resolution: No change

Fixed.

Issue 16-14. Status: closed

From Andreas Strotmann

 - instead of a condition, domainofapplication may also be used
    (see long rationale in previous message)

     (bvar, domainofapplication, anything) -> set
     (domainofapplication, function) -> set

     e.g. {x^n|x\in N}:  set(bvar(x),dom-of-app(N),apply(pow,x,n))
          sin(N) :       set(dom-of-app(N),sin)
    

Proposed resolution: Spec fix

Fixed signatures, and added a new example.

Issue 16-15. Status: closed

From Andreas Strotmann

C.2.6.4

  - union correctly allows zero args, so why not intersect?
    

Proposed resolution: Spec fix

Fixed.

Issue 16-16. Status: closed

From Andreas Strotmann

C.2.6.7,.8

  - like the lt/gt/leq... predicates, subset and its cousin are often
    seen as chains   A subset B subset C..., and should thus be n-ary in
    their signatures.
    

Proposed resolution: Spec fix

Added new examples of subset and prsubset
illustrating use of bound variables and conditions

Issue 16-17. Status: closed

From Andreas Strotmann

C.2.7.1,.2

  - first sentence, delete 'a' before 'domains'
    

Proposed resolution: Spec fix

Reworded the entire paragraph as it was the leadin to sum.
Also fixed product.	
Main thrust was to talk about domainofapplicaiton instead
of shorthand notes first.

Issue 16-18. Status: closed

From Andreas Strotmann

- signature should include domainofapplication
    

Proposed resolution: spec fixed

Fixed

Issue 16-19. Status: closed

From Andreas Strotmann

- case of zero bvars with domainofapplication requires functional arg
    

Proposed resolution: Spec fix

Fixed

Issue 16-20. Status: closed

From Andreas Strotmann

C.2.7.3

  - description says 'one or more bvars', signature says zero or more
    

Proposed resolution: Spec fix

Fixed the signature

Issue 16-21. Status: closed

From Andreas Strotmann

  - neither example is licensed by the rest of the spec. They both
    use two normal args instead of condition followed by arg.
    

Proposed resolution: spec fix

Fixed.

Issue 16-22. Status: closed

From Andreas Strotmann

C.2.7.4

  - this element illustrates the need to sometimes use more than one
    type attribute.  In this case, their can be a difference whether
    tendsto applies over the reals and from above or whether it applies
    over the complex numbers, say.
    

Proposed resolution:

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.

Issue 16-23. Status: closed

From Andreas Strotmann

C.2.8.1,.2,.4--.27

  - missing parentheses around LHSs of signatures
    

Proposed resolution: Spec fix

Fixed

Issue 16-24. Status: closed

From Andreas Strotmann

C.2.8.4--.27

Description
  - add 'full' names in parentheses, as in 'sin (sine)', 'cos (cosine)'
    

Proposed resolution:

Not changed for editiorial consistence. References to formal definitions of the functions are provided

Issue 16-25. Status: closed

From Andreas Strotmann

C.2.9

  - previous general comments on nary functions apply here in several places
    

Proposed resolution: Spec fix

extended qualifiers to each of mean, median and mode.

Issue 16-26. Status: closed

From Andreas Strotmann

C.2.9.1

  - spurious paragraph break
    

Proposed resolution: Spec fix

Fixed.

Issue 16-27. Status: closed

From Andreas Strotmann

C.2.9.2,.3

   - typo in second signature (descrete -> discrete)
    

Proposed resolution: Spec fix

Fixed.

Issue 16-28. Status: closed

From Andreas Strotmann

C.2.9.3

   - signature allows a single scalar arg, description requires at least
     two.
    

Proposed resolution: Spec fix

Fixed.

Issue 16-29. Status: closed

From Andreas Strotmann

C.2.9.7

  - classification should be qualifier
    

Proposed resolution: Fix

Fixed.

Issue 16-30. Status: closed

From Andreas Strotmann

C.2.10.1

  - the second signature should not restrict the allowable child elements
    

Proposed resolution: Spec fix

Fixed.
and added additional signatures for
those with qualifiers.

Issue 16-31. Status: closed

From Andreas Strotmann

- general comments on n-ary functions apply here too. In particular,

       v:= (f_i)_i=1..n

    is very common (especially in numerical maths) and should be
    expressible as

      declare(v,vector(bvar(i),lowlimit(1),uplimit(n),f(i)))
    

Proposed resolution: spec fix

This is now supported

Issue 16-32. Status: closed

From Andreas Strotmann

C.2.10.2

  - the second comment from C.2.10.1 applies here mutatis mutandis.
    In my comments on chapter 4 I discuss this in more detail
    

Proposed resolution: Spec fix

Now supported

Issue 16-33. Status: closed

From Andreas Strotmann

C.2.10.5

  - missing closing parenthesis in second signature
    

Proposed resolution: Spec fix

Fixed.

Issue 16-34. Status: closed

From Andreas Strotmann

C.2.10.6

description
   - 'by selecting one fewer items' - remove 'one'
    

Proposed resolution: Spec fix

Fixed.

Issue 16-35. Status: closed

From Andreas Strotmann

properties
   - second property is incorrect  (matrix requires sequence of
     matrixrows, not sequence of scalars)
    

Proposed resolution: Spec fix

changed to use matrixrow instead of matrix

Issue 16-36. Status: closed

From Andreas Strotmann

C.2.11.2

missing opening parenthesis in first property
    

Proposed resolution: Spec fix

Fixed.

Issue 16-37. Status: closed

From Andreas Strotmann

C.2.11.3

first and third properties are the same
    

Proposed resolution: Spec fix

Fixed by deleting last one.

Issue 16-38. Status: closed

From Andreas Strotmann

C.2.11.6

first property:  use 'factorof' instead of 'divide'
    

Proposed resolution: Spec fix

Fixed.

Issue 16-39. Status: closed

From Andreas Strotmann

C.2.11.10,(.11)

first property:  use <false/> instead of <cn...>
    

Proposed resolution: Spec fix

Fixed.

Issue 16-40. Status: closed

From Andreas Strotmann

second property:  wrap in <math> element (because of declare)
    

Proposed resolution: No change

No math tag wrappers. This is to avoid
special cases in the production process
and to support consistency throughout the
rec.

Issue 16-41. Status: closed

From Andreas Strotmann

C.2.11.13

signature should read 'real constant'
    

Proposed resolution: Spec fix

Fixed

Issue 20-1. Status: closed

From Bill Naylor

I noticed a bug in the property associated with section C.2.8.16 arcsin,
the property says:

arcsin(z) = -i ln (sqrt(1-z^2)-iz)
it should be :
arcsin(z) = -i ln (sqrt(1-z^2)+iz)

the property for arctan talks about log, when it should talk about ln, log
being reserved for the more general version, taking a base.
    

Proposed resolution: Spec fix

Issue 21-1. Status: closed

From Clare So

The signature of <limit> (section C.2.7.3) is 

    (bvar*, ( (lowlimit, uplimit) |condition ), algebraic) -> real

and the examples in this section are:

<apply><limit/>
  <apply>
    <tendsto type="above"/>
    <ci>x</ci><cn>0</cn>
  </apply>
  <apply><sin/><ci>x</ci></apply>
</apply>

<apply><limit/>
  <apply><tendsto/><ci>x</ci><cn>0</cn></apply>J
  <apply><sin/><ci>x</ci></apply>
</apply>

Should the first <apply> child be <condition>?

Proposed resolution: Spec fix

Fixed

Issue 22-1. Status: closed

From Rick McGowan

Sorry to be outside the "last call" period ending May 9, but members of  
the Unicode Technical Committee have just been made aware of your new  
MathML document here:

http://www.w3.org/TR/2003/WD-MathML2-20030411/

I was checking section 6.3.5 for anomalies as compared to the latest  
Unicode data files here:

http://www.unicode.org/Public/4.0-Update/StandardizedVariants-4.0.0.txt

The proposed MathML spec lists some things that don't appear in  
StandardizedVariants of Unicode 4.0.

I just compared the list against StandardizedVariants.txt of 4.0.

There are four things listed in MathML list that are NOT in  
StandardizedVariants for Unicode 4.0:

2225
2278
2279
2A3B

There is only one thing listed in StandardizedVariants for 4.0 that is NOT  
shown in the MathML list:

2A3D FE00; tall variant with narrow foot; # RIGHTHAND INTERIOR PRODUCT

Also the document still refers to Unicode 3.2, though 4.0 has been  
published since mid April. Someone there should cross-check the Unicode  
references against Unicode 4.0 data files to verify my findings.
    

> I just compared the list against StandardizedVariants.txt of 4.0.

At some point I did mechanically check the mathml variants list against
a draft of the StandardizedVariants document and a draft of TR25, but
either the draft changed or later hand edits on our side have caused
these differences (or it sems more likely, a combination of all these
things, see below.)

I already had an action item to double check this list before the next MathML
draft, so thanks for pointing out these discrepancies. They will
certainly be fixed in the next draft (which should be this month with a
bit of luck).

> There are four things listed in MathML list that are NOT in  
> StandardizedVariants for Unicode 4.0:

This is clearly bad, and will be deleted.

I note 2 of the 4 that you list:

2278
2279

are in StandardizedVariants-4.0.0.txt but commented out, and are in the
files I actually used:

http://www.unicode.org/Public/3.2-Update/StandardizedVariants-3.2.0.html
http://www.unicode.org/unicode/reports/tr25/

Which explains how they came to be there, although however they got
there they should clearly go now to align with unicode 4.

> There is only one thing listed in StandardizedVariants for 4.0 that is NOT  
> shown in the MathML list:

We may as well list this one as well, for completeness,

Unless I have missed something the lack of a variant of 2225 introduces
another unfortunate case where unicode doesn't have enough characters to
support the ISO entity sets in any plausible way, in this case parsl in
ISO 9573 part 13 ISOTECH. It would be _really_ helpful if Unicode 4.x
would add characters to cover the ISO entity sets. It is very hard to
automate safe conversion of SGML (with SDATA entities) to XML (with
entities expanding to Unicode) without these characters.



> I hope this information reaches the right people.

It did.

> Also the document still refers to Unicode 3.2, though 4.0 has been  
> published since mid April.

Yes, adding unicode 4 (and a reference to the new unicode 4 script l)
is already in the pipeline for the next draft.

[...]

I wrote

> Unless I have missed something the lack of a variant of 2225 introduces
> another unfortunate case where unicode doesn't have enough characters to
> support the ISO entity sets 

In this case I think I missed 2AFD DOUBLE SOLIDUS OPERATOR However the
general principle that Unicode could (and probably should) support all
the ISO entities is still valid I believe.

You mentioned:

> I note 2 of the 4 that you list:
> 2278
> 2279
> are in StandardizedVariants-4.0.0.txt but commented out, and are in the
> files I actually used:

Right. Just FYI and for future reference: these two characters 2278 and  
2279 originally were in our list but then they got removed. This was an  
action taken by UTC, based on a paper by Mark Davis 2001-03-28, document  
reference L2/02-126. The decision was based on the fact that 2278 and 2279  
are decomposable characters. UTC issued a corrigendum to remove these.  
There is an explanation of this in Unicode Technical Report #28 (Unicode  
3.2). An errata report was filed to the MathML WG on 02 April 2002 by  
Martin Duerst.

> Unless I have missed something the lack of a variant of 2225 introduces
> another unfortunate case where Unicode doesn't have enough characters to 
> support the ISO entity sets in any plausible way, in this case parsl in
> ISO 9573 part 13 ISOTECH. It would be _really_ helpful if Unicode 4.x
> would add characters to cover the ISO entity sets. It is very hard to
> automate safe conversion of SGML (with SDATA entities) to XML (with
> entities expanding to Unicode) without these characters.

Someone will need to gather the relevant info and propose this. Probably  
fairly easy to get this rolling. I would suggest that Asmus Freytag is the  
person to help coordinate this proposal. I'm CCing him on this note...

Proposed resolution: Spec fixed.