Harmonize WeBWorK math

[rbeezer]

Some ideas about math bits in WeBWork problems and harmonizing with changes elsewhere. Compare recently-adjusted templates in xsl/mathbook-html.xsl and xsl/mathbook-webwork-pg.xsl

• men, mdn are not relevant in a WW problem. Should we kill them entirely in this case and issue a (fatal) error/warning?
• HTML and LaTeX templates condition on a "webwork" ancestor. This would appear unnecessary?
• Do we want to support "fillin" within math within "webwork"? How about "xref"? The first may be redundant (answer blanks exist?), the latter may be impossible (a bit brittle for HTML already).
• I have the whitespace switch implemented for math bits. How careful do we need to be about indentation, line breaks, etc.? There could be big savings here in character count for base64 encoding. Typical example is a matrix, which may be authored across several lines, but output as part of one line.
• The detection of gathered v. aligned is imperfect. An environment that should be gathered may be aligned due to ampersands in a matrix. We have @alignment attribute to manually override this. Do we want this here? See default template for this, where maybe we just add "ed" if a "webwork" descendant.

[Alex-Jordan]

I think #509 (or alterations to it) should be merged before more happens with the webwork XSL.

Initial responses in order:

• Killing men, mdn would be fine.
• Conditioning on a webwork ancestor is intentional now. I could put a comment. The reason has something to do with templates from mathbook-webwork-pg.xsl tying with those from mathbook-html.xsl, and the order that they need to be loaded. So we made the mathbook-webwork-pg.xsl templates more specific. Of course, this doesn't apply to LaTeX. I'd want to look at those.
• Is fillin easy to support? I don't think I'd ever use it, but it's nice to trty to get things that work one place to work elsewhere, so authors need not concern themselves with what works where. You mean xref within math? I think that would be valuable in a solution that cited references for steps in a multiline equation.
• I believe that within math mode, PGML is not paying attention to whitespace, so I'm not concerned on that point. However, we make PG for two purposes. One is for the HTML to put into base64; there, shorten away. The other purpose is to archive problems. Faculty might one day want to customize their version of the problem within WeBWorK, having nothing to do with the original MBX source. For them, the code should remain human-readable. So I'd be more careful there. We do need to start talking about separating these two processing modes for other reasons as well.
• Sounds good. As someone who never uses gather(ed), I haven't though about these things.