RE: Draft Node: Fill in the Blank

Hi,



Time ago we faced a similar problem that we fixed it using the maction tag.
For us was the natural choice because denotes more a behaviour of the
formula than a styling issue. For example,



<math xmlns="http://www.w3.org/1998/Math/MathML">

      <mi>x</mi>

      <mo>+</mo>

      <maction id="a" actiontype="argument">

            <mtext>a</mtext>

      </maction>

  </math>



Where the blank (we called then argument) has the label a. Now, any
possible MathML renderer might allow editing the content of the maction.
With proper styling (css) and event raising (onchange, onkeypress, etc.) a
lot of addition behaviour can be provided.



On the other hand, displaying a correct answer can be done perfectly with
styling (css).



Once again, I do not think that the objective of MathML is expressing the
whole semantics of a question with correct answer, the input box, grading
criteria or any feedback.



Dani





*From:* Paul Libbrecht [mailto:paul@hoplahup.net]
*Sent:* lunes, 09 de julio de 2012 7:22
*To:* Paul Topping
*Cc:* Neil Soiffer; www-math@w3.org
*Subject:* Re: Draft Node: Fill in the Blank





Le 7 juil. 2012 à 21:34, Paul Topping a écrit :




If we allow several expressions associated to a blank then it also

makes sense to allow one that allows the recipient user-agent (e.g. a

web-page with some javascript) to compare the user-input with the one

(given some flexibility).


So this would be the "correct answer" typically, right? I imagine that some
won't want to use that as it would be open to cheating by anyone that can
View Source on the page. Still, that's probably not a reason to omit it.



It would be an basis for a correct answer, whichever that basis is.

It could allow, for example, a stateless direct communication to an
evaluation service and this data would then be used as a predicate or
function to evaluate where to go once this is submitted; see an example
below.



My concern now is whether it is good to allow multiple children. From

this discussion it sounds unavoidable. And if we do so, how do we

markup so that renderers that are unaware of this note still render

something partially useful?


Can we not tell page authors to use CSS in the page source HTML to hide
those parts that should not be visible?



I'm surprised this is coming of you since MathPlayer would have to
implement CSS extra for it to work, if I do not mistake.



I am thinking that for more complex expressions there are better markups
for this.



One possibility, that would change radically the current, is to use the
semantics and annotation-xml representations alternatives as below. This
should be processed by all MathML-compliant processors into ignorance for
all but the first child of the semantics element and for, those would would
support fill-in-the-blanks, into an expression with a more elaborate
function.



But this looks like too radical a change.



Paul



<semantics>

  <mrow>....(I am a prompt)....</mrow>

  <annotation-xml cd="fill-in-the-blanks" name="phantom"
encoding="MathML-presentation">

            <mroot><mfrac><mrow>1</mrow><mrow>x^2+1</mrow></mroot>

  </annotation-xml>

 <annotation-xml cd="fill-in-the-blanks" name="evaluator"
encoding="OpenMath">

        <OMOBJ xmlns="http://www.openmath.org/OpenMath">

          <OMBIND>

            <OMS cd="fns1" name="lambda" />

            <OMBVAR>

              <OMV name="f" />

            </OMBVAR>

            <OMA>

              <OMS cd="arith1" name="plus" />

              <OMA>

                <OMS name="minus" cd="arith1" />

                <OMV name="f" />

                <OMA>

                  <OMS cd="arith1" name="divide" />

                  <OMI>1</OMI>

                  <OMI>1</OMI>

                </OMA>

              </OMA>

              <OMA>

                <OMS cd="arith1" name="power" />

                <OMV name="x" />

                <OMI>2</OMI>

              </OMA>

            </OMA>

          </OMBIND>

    </annotation-xml>

</semantics>

Received on Monday, 9 July 2012 11:26:02 UTC