ISSUE-8: New Symbols for Lifted Operators

New Symbols for Lifted Operators

Raised by:
Michael Kohlhase
Opened on:
MathML2 generically allowed the use of n-ary operators as binding operators with
bound variables induced by them. For instance union could be used as the
equivalent for the TeX \\cup as well as \\bigcup. While the relation between the
nary and the set-based operators is deterministic, i.e. the induced big
operators are fully determined by them, the concepts are quite different in
nature (different notational conventions, different types, different occurrence
schemata. I therefore propose to extend the MathML K-14 CDs with symbols big
operators, much like we already have sum as the big operator for for the n-ary
plus symbol, and prod for times. For the new symbols, I propose the naming
convention of capitalizing the big operators (as an alternative, we could follow
TeX and pre-pend a bib). For example we could have Union as a big operator for union
Related Actions Items:
No related actions
Related emails:
  1. RE: ISSUE-8: New Symbols for Lifted Operators (from on 2007-02-08)
  2. ISSUE-8: New Symbols for Lifted Operators (from on 2007-02-06)

Related notes:

There are some very important issues here:

1. Semantically, a sum, union, product, etc. are all sums regardless of the
notation used to specify the summands. This is consistent with the current
mathml markup.

2. The fact that a sum over a set, or over a sequence of unspecified size needs
a different syntax (using bvar) does not change this fact.

3. The introduction of BigSum, etc. can be regarded as driven more by
presentational concerns than semantics.

What it comes down to is this. There are three main (say) sums: explicit,
sequenced, and over a set. The current mathml model already handles all 3 and
distinguishes between them by simply looking at the content model.

It is possible to introduce three different containers, each with only one
content model but look at the consequences:

1) Every \"official\" operator now needs three versions.

2) We also now need three different content models for <apply>, since every
user defined operator can in principle operate discretely, over an enumerated
sequence, or over a set.

3) We have locked into just these three models.

XML is good at flexible containment - re-use of the container for different
content models. If OpenMath wants to stay with unique containers for different
content models, that is fine. As Michael points out, it is already very clear
how to get there.

Do we really want to complicate apply, and triple the number of defined element
operators, and introduce legacy complications just to retain the same functionality?

8 Feb 2007, 00:00:00

Also, note that with the new cd referencing attributes you already have a way of
distinguishing which CD to goto explicitly without adding new operators.

8 Feb 2007, 00:00:00

this has been amicably resolved a while ago, closing the issue

Michael Kohlhase, 8 May 2008, 06:13:37

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 8.html,v 1.1 2016/05/09 13:05:45 carine Exp $