sidebyside for WeBWorK 2.19

[Alex-Jordan]

There are three commits here. The first one makes some changes to xsl files and pretext.py. You could apply only that commit, and then make sample-chapter-representations and you will see only a few (not meaningful for output) changes:

• A change with how tabulars end, putting the closing delimiter on a new line.
• The base 64 encodings are occasionally different. This is just because of an unnecessary extra blank line being removed.

Both of these changes are just side effects of making the following possible.

The second commit adds an example to the sample chapter. If you apply that commit as well, and try to make sample-chapter-representations, it will give you an error message. Because this feature is only possible with 2.19, and the AIM server is still 2.17. (It would also work with 2.18, if 2.18 gets some bugs hotfixed.)

Now to continue testing, change the server (in the publisher file) to webwork-dev.aimath.org, which is 2.19 (not fully the final 2.19 release version, but getting there as we get closer to summer). Now do make sample-chapter-representations. It will work. You can continue on to make the HTML and PDF and see the sidebyside~s working.

Lastly, as long as the default WW server is the AIM server and it's still 2.17, it seemed wise to comment out this example. Or if you prefer we could handle this issue on some other way.

[rbeezer]

I got partway through this - thanks for the careful testing regimen.

• Is the 2.19 JS in the first commit (which we already have now)?
• Un-supported elements. Interesting scheme. ;-) You never actually use the element named element by name, do you? It is just a child of unsupported. Could it have a less-generic name?
• I think $b-human-readable does not belong in -common. Will the code behave if you set the true() default in the definition of the mode="panel-panel" template in extract-pg.xsl.
• I've been fooled many times by large chunks of source being commented-out and grep giving me false-postives that I can't see are inside these chunks. The test document and the server version used should match ideally. Not sure about the best resolution. Putting the example on a commit you have custody of locally might be the best option. Then the XSL, etc can be tested once you increment servers and make a PR with that commit.

[Alex-Jordan]

Well, there is some conflict now and will resolve sometime soon. But I don't think it is the 2.19 js. The other recent PR made a proper file for the 2.18 js, but did not make a 2.19 js file. Yes, that is in the first commit.

Un-supported elements. Interesting scheme. ;-) You never actually use the element named element by name, do you? It is just a child of unsupported. Could it have a less-generic name?

I could make it that way now. But I imagine this scheme will extend to three things:

• A PTX element that by rights should be valid, but the WW translation does not support it (eg sidebyside when the WW version is old).
• A PTX attribute that by rights should be valid, but the WW translation does not support it.
• A WW coding construct in the pg-code that did not come about until a particular version of WW.

So I was thinking unsupported/element, unsupported/attribute, unsupported/pg or something like that. And if it's not clear, it's all a bit awkward because the publisher is the one who picks the WW server, and subsequently our python detects the WW version which the publisher might not even know about. Meanwhile the author wrote the source. We don't know the WW version until building representations, and can only assess if things are unsupported at that time. Rather than inefficiently look through the tree at that point in the build, the extraction is jotting down the things that might be an issue depending on the WW version.

An alternate approach would be less efficient, but we could just look through the tree for the unsupported things while the python is running to do the extraction.

I think $b-human-readable does not belong in -common. Will the code behave if you set the true() default in the definition of the mode="panel-panel" template in extract-pg.xsl.

PG wants to keep passing $b-human-readable down through all the elements. The general sidebyside constructor goes back from a stylesheet like extract-pg.xsl to -common and back. So if we don't handle it in -common, the value of $b-human-readable gets lost. With your suggestion, the PG code still works, but we would lose the compression we get in the non-human readable version for all content within a sidebyside.

Maybe I can find a way to eliminate the $b-human-readable param, and instead make it all based off of some variable set in assembly. Haven't thought hard about it yet but I know that kind of thing can be tricky since WW gets processed multiple times.

I've been fooled many times by large chunks of source being commented-out and grep giving me false-postives that I can't see are inside these chunks. The test document and the server version used should match ideally. Not sure about the best resolution. Putting the example on a commit you have custody of locally might be the best option. Then the XSL, etc can be tested once you increment servers and make a PR with that commit.

That's fine with me. I just wanted to give you an example to test with when it's ready, to see that the sbs really works.

[rbeezer]

but did not make a 2.19 js file

Should we do just that on a separate commit now?

instead make it all based off of some variable set in assembly

Yes, that's my thought. And that variable might already exist, by another name. You might be able to just duplicate its value into a global "human readable" in pg-extract.xsl and then simply eliminate teh parameters and all teh rest of the code is unchanged. Or something like that.

example to test with when it's ready, to see that the sbs really works.

Yes, thanks.

More later - off to things happening "locally". ;-)