Geogebra material-id implemented using implicit slate

[dbrianwalton]

Revised the implementation of interactive[@geogebra] so that during assembly this is converted to adopt an implicit slate such that the Geogebra applet can be loaded directly rather than rely on the less-reliable URL approach for accessing material-ids.

Consists of two commits in order to separate out the removal of the original template that accessed the material using a coded Geogebra URL.

I don't have access to a pool of test cases, so I have only been able to test a few examples.

[dbrianwalton]

@rbeezer Can you pay particular attention to line 1760 in pretext-assembly.xsl where I create the slate and assign an auto-generated xml:id. Based on the stage we are in during assembly, I think it is valid to use @assembly-id of the interactive to generate a new id, but I'm still trying to grasp all of the different ids/labels and their appropriate uses.

[rbeezer]

I'm still trying to grasp all of the different ids/labels and their appropriate uses.

Me, too. I'll give it a hard look.

[dbrianwalton]

If you think this looks good, I'll also update the sample-article to give updated instructions. Need to have material-width on the interactive to push into the slate. Also, I added additional flags for geogebra control (zoom-controls). I should have another commit for this quickly.

[rbeezer]

Well, this became a production, huh? Visual inspection looks good.

I'm leery of having too many "passes" in the assembly phase. Will we run out of memory with too many different copies of the entire source? (Or is there good garbage collection?) I don't really know, but I'd lean towards not adding a new pass just for GeoGebra. Do you think it could be part of "assembly"? I first thought of "augment", but I think I will reserve that for numbering.

I think @assembly-id is right at this point. Do we want to manufacture an @xml:id or a @label? I guess the former is more consistent. Any generated value (such as the -ggb-slate prefix runs the risk the author has an @xml:id somewhere else which is identical. But I guess that is rare enough to not be such a problem.

Not seeing anything else big right now. I'll try to take this for a real drive very soon.

[dbrianwalton]

I think this is contained enough that it could easily merge into a different stage of assembly. I couldn't clearly identify which existing stage made the most sense, but looking at what I could find just now about assembly, I don't anticipate a complication. I see that this does include some organization of exercise, and a geogebra element could exist in such a setting, but should not really disrupt the assembly restructuring since everything is contained within an interactive.

[dbrianwalton]

I started exploring putting this in assembly. I need some guaranteed id to build the slate's id, but assembly occurs before assembly-id is generated. So then I switched to the "enrichment" stage and seem to be getting identical assembly-dynamic results between the two. I'll push this additional commit.