Open Alex-Jordan opened 3 months ago
I got partway through this - thanks for the careful testing regimen.
element
by name, do you? It is just a child of unsupported
. Could it have a less-generic name?$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
.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:
sidebyside
when the WW version is old).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.
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". ;-)
There are three commits here. The first one makes some changes to xsl files and
pretext.py
. You could apply only that commit, and thenmake sample-chapter-representations
and you will see only a few (not meaningful for output) changes: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 domake 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.