Elision in different elision groups is not always independent

[frabe]

ich bin auf folgendes Problem gestoßen:

OMA

OMS plus s OMATTR

OMATP

OMS typeof T

/OMATP t

/OMATTR

/OMA

könnte zum Beispiel präsentiert werden als

s + (t:T)

was durch Elision der type ascription zu

s + t

verkürzt werden kann. Aber das funktioniert nicht immer: Manchmal muss die Elision der type ascription zu

s + (t)

führen. Das können wir momentan nicht.

[frabe]

I think we have to do this.

Every elidable component gets an additional offset attribute, e.g., <maction action="elision" selector="2"  omdoc:elevel=L  omdoc:offset=O>

(t) (t:T)

</maction>

At view time the event threshold > L results in a traversion of the document that sets selector="1". When recursing into the children, the offset O is added to the threshold.

Thus, eliding certain parts may result in other parts appearing.

The rendering process would compute the offset as the difference of the input precedence and the next higher input precedence.

[frabe]

The solution outlined above is very specific. We might also come up with something much more general.

For example: Every elidable component has a condition attribute which contains some formula using special constants for the thresholds. The viewer then has to parse and evaluate this formula to determine the visibility.

[frabe]

In any case Presentation MathML should allow references to other parts of the presentation. For example:

<maction action="elision" selector="2">

<mrow id="a">t</mrow> ( <mref ref="#a"/> : T )

</maction>

Or does that already exist? I couldn't find it in the spec.

[frabe]

I like my second suggestion better now. The value of the condition attribute should be formed from:

• variables (replaced with threshold values)
• leq(s,t), geq(s,t), etc.
• F & G, F | G etc.

[clange]

Replying to frabe:

<maction action="elision" selector="2"> <mrow id="a">t</mrow> ( <mref ref="#a"/> : T ) </maction> Or does that already exist? I couldn't find it in the spec.

So far I haven't seen it either, but as OpenMath? supports it, Content MathML 3 should support it as well, and then it would make sense to add this support to Presentation MathML 3, too.