# ISSUE-8: New Symbols for Lifted Operators

## New Symbols for Lifted Operators

- State:
- CLOSED
- Product:
- All
- Raised by:
- Michael Kohlhase
- Opened on:
- 2007-02-06
- Description:
- 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:
- RE: ISSUE-8: New Symbols for Lifted Operators (from stan.devitt@gwi-ag.com on 2007-02-08)
- ISSUE-8: New Symbols for Lifted Operators (from dean+cgi@w3.org 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?

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.

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

Michael Kohlhase, 8 May 2008, 06:13:37Display change log